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Prefacio 


Los grandes avances realizados en las tecnologías de la información y de las comunicaciones (TIC) han ele- 
vado nuestra capacidad de generar y compartir información hasta límites insospechados, y con esta capacidad 
también han aumentado los riesgos que ello supone. 


El mundo electrónico-digital tiende a reemplazar a los antiguos sistemas, más lentos e ineficientes. Algunos 
ejemplos cotidianos los encontramos en el correo electrónico, el comercio electrónico, la votación electrónica, 
la administración digital, la televisión digital, etc. El mundo de lo electrónico y lo digital está llamado a ser 
el dominante y es por ello que resulta de vital importancia el estudio de teorías y métodos que permitan 
garantizar la privacidad y la seguridad de los usuarios en este nuevo contexto. 


Con esta idea en mente, y con el objetivo de servir de foro de intercambio de conocimientos para los inves- 
tigadores, en 1991 nació la Reunión Española sobre Criptología y Seguridad de la Información (RECSL), la cual 
en aquel entonces vino a llamarse Primera Jornada Española sobre Criptografía. 


Este año, Tarragona acoge en septiembre la undécima edición de la RECSI, el congreso científico español de 
referencia en el ámbito de la seguridad en las tecnologías de la información. Las pasadas ediciones se realizaron 
en Palma de Mallorca (1991), Madrid (1992), Barcelona (1994), Valladolid (1996), Torremolinos (1998), Santa 
Cruz de Tenerife (2000), Oviedo (2002), Leganés (2004), Barcelona (2006) y Salamanca (2008). 


La ciudad de Tarragona ha sido testigo de generaciones cuyas huellas han merecido el reconocimiento 
mundial. Como elemento representativo de esta RECSI hemos elegido la muralla, símbolo de los vestigios de 
la Tarragona Romana y uno de los muchos elementos patrimoniales que recomendamos visitar. 


Estas actas contienen las 72 contribuciones de la RECSI 2010, cuyas sesiones se organizan en los siguientes 
ámbitos temáticos: cifrado de flujo, clave pública, criptoanálisis, firmas digitales, privacidad, protocolos, RFID, 
seguridad, seguridad de redes, watermarking y fingerprinting. Como conferenciantes invitados contamos con 
Ronald Cramer (Centrum Wiskunde éz Informatica, Amsterdam) y Paulo Veríssimo (Universidad de Lisboa). 


Desde la organización queremos expresar nuestro agradecimiento a todos los patrocinadores y colabo- 
radores del evento, así como también a todos los ponentes, asistentes, miembros de los comités y revisores. 


La compilación de las actas se realizado con IXTÉX y el paquete *confproc”. 


Tarragona, septiembre de 2010 


Josep Domingo Ferrer 
Jordi Castella Roca 
Antoni Martínez Ballesté 
Agustí Solanas Gómez 
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Criptografía de alta velocidad: 
Cifrando en condiciones extremas 
(grandes cantidades de datos en tiempo escaso) 


Vicente Jara Vera 
Carmen Sánchez Ávila 
Grupo de Biometría, Bioseñales y Seguridad (GB25) 
Centro de Domótica Integral (CeDInt) 
Universidad Politécnica de Madrid, Madrid, España 
Email: (vjara,csa) Qmat.upm.es 


Abstract—Inicialmente al cifrado se le pide seguridad, pero 
hay entornos en los que además se precisa cifrar una gran 
cantidad de datos en un tiempo aceptable. La gran cantidad 
de datos que cada vez se van manejando en las redes actuales, 
servidores, sistemas de comunicación, puntos de routing, e incluso 
ordenadores y máquinas individuales hace preciso contar con 
sistemas que permitan cifrar volúmenes tan grandes como los 
Gygabytes en tiempos tan cortos o escasos como uno o dos 
segundos. Ofrecemos en este estudio la situación actual (2010) 
en cuanto a la existencia, o no, de criptosistemas que permitan 
realizar esta tarea, así como la sugerencia de cuáles usar en los 
distintos entornos que pudieran presentársenos. 


I. INTRODUCCIÓN 


Cifrar gran cantidad de datos en condiciones donde el 
tiempo es reducido es una situación que en algunos entornos 
puede ser necesario realizar e incluso hacerlo de manera 
habitual, lo que hace preciso el disponer de criptosistemas 
que se adecuen a estas necesidades. 

Este es precisamente el caso que estamos considerando en 
este trabajo, buscar los cifradores más rápidos existentes en 
la actualidad sin perder, claro esta, la inherente capacidad 
de seguridad que se espera de un criptosistema, ya que la 
velocidad en las operaciones del cifrador no ha de ser óbice 
para rebajar la dificultad de ruptura del sistema criptográfico. 

El entorno es sumamente restrictivo, ya que si hablamos 
de velocidad alta de cifrado estamos pensando en cifrar 
volúmenes hoy en día considerados grandes (Gigabytes) en 
tiempos pequeños (segundos). Este intento, ya lo decimos, 
no tenía solución hace alrededor de 6-8 años, pero hoy sí 
existen sistemas capaces de lograr tales cotas de eficiencia. 
Nuestro propósito es mostrar un elenco de la situación actual 
en base a los mejores criptosistemas existentes en sus distintas 
variantes (asimétricos y simétricos) para trabajar en situaciones 
o entornos como el planteado. 


II. CRIPTOSISTEMAS SIMÉTRICOS Y ASIMÉTRICOS 


La división de la Criptografía como una Ciencia puede 
hacerse en base a dos hechos significativos que son punto 
de inflexión en la misma. Primeramente, el artículo de 1.948 


Gonzalo Bailador del Pozo 
Javier Guerra Casanova 
Alberto de Santos Sierra 
Grupo de Biometría, Bioseñales y Seguridad (GB2S) 
Centro de Domótica Integral (CeDInt) 
Universidad Politécnica de Madrid, Madrid, España 
Email: [gbailador,jguerra,alberto) E cedint.upm.es 


de Claude Shannon sobre Teoría de la Información y Crip- 
tología, “A mathematical Theory of Communications” [1]: 
es el comienzo de la consideración de la Criptología no ya 
como un Arte apartado y misterioso, sino como una rama de 
la Matemática. El segundo acontecimiento es la publicación 
en el año 1.976 de un artículo por Whitfield Diffie y Martin 
Hellman, “New Directions in Cryptography” [2], en el que 
proponen un nuevo sistema de cifrado, el de clave pública. 
Este segundo artículo supuso la división de los criptosistemas 
en sistemas de clave secreta O simétrica y sistemas de clave 
pública o asimétrica. 

1) Criptosistemas asimétricos: Los cifradores más rápidos 
son los cifradores simétricos, ya que los asimétricos descansan 
en la ejecución de procedimientos y algoritmos matemáticos 
basados en problemas de complejidad difíciles de resolver, que 
hacen que sean más lentos en ejecutarse que los simétricos, 
basados en operaciones matemáticas más rápidas, a veces 
repetitivas, que añaden confusión y difusión -como especi- 
ficaba Claude Shannon [1]- a los datos en claro de entrada. 
Los sistemas simétricos o de clave secreta a su vez pueden 
catalogarse como cifradores de bloque y de flujo o “stream”, 
según cifren un conjunto de bits a la vez o bien vayan cifrando 
bit a bit, respectivamente. 

No obstante, y debido a que el cifrado de los datos se hace 
simétricamente, y sólo se usa el cifrado asimétrico para la 
clave de aquel, no será su lentitud un problema y no serán 
objeto de nuestro estudio, aunque haremos seguidamente una 
somera mención de sus capacidades de ejecución. 

Así, entre los más conocidos criptosistemas asimétricos y 
que se consideran seguros, indiquemos que McEliece [3] no 
siendo lento ofrece unos tamaños de claves sumamente gigan- 
tescos; RSA [4] o ElGamal [5], que se basan en el Problema 
de la Factorización el primero, y en el Problema del Logaritmo 
Discreto el segundo, son más lentos ( [6], [7], [8], [9] ), que 
el cifrado de Curvas Elípticas, basado en el Problema del 
Logaritmo Discreto en este Grupo algebraico ( [10], [11] ). Los 
sistemas Benaloh [12], Goldwasser-Micali [13], Damgaard- 
Jurik [14], Naccache-Stern [15], Okamoto-Uchiyama [16] o el 


de Paillier [17], se basan en el Problema de la Residuosidad 
Cuadrática o la Compuesta y son como mucho problemas 
similares al de la Factorización, lo que los convierte en simi- 
lares a RSA en velocidad por la ejecutoria de las operaciones 
matemáticas de los algoritmos involucrados; otros sistemas 
son el de Blum-Goldwasser [18], que a pesar de ser de tipo 
“stream”, no llega a obtener tan buenos resultados en velocidad 
como el de Curva Elíptica [19]; por otro lado, los que se basan 
en el Problema del Logaritmo Discreto, y citamos entre otros 
a CEILIDH [20], Cramer-Shoup [21], y XTR [22], no son 
tan seguros como el de Curva Elíptica [23] y son siempre 
inferiores a éste en velocidad ( [24], [25] ), aunque el último 
se acerca a él [22]. 

2) Criptosistemas simétricos en bloque: El criptosistema 
simétrico en bloque por excelencia hasta la aparición de 
AES [26] en el año 2.002 ha sido DES [27], el cual es 
alrededor del doble de lento que el nuevo cifrado simétrico 
estándar. Siguiendo el único estudio de velocidades realizado 
sobre los 15 candidatos a mejor cifrado simétrico en los 
EE.UU por el NIST [28] podemos concluir que si se im- 
plementa en software el cifrado en microprocesadores de 32 
bits los mejores candidatos para cifrar grandes cantidades 
de datos son Twofish [29], Rijndael [30] (el original AES, 
antes de ser redefinido por el estándar), CRYPTON [31], 
RC6 [32] y MARS [33], y para pequeñas cantidades Rijndael, 
CRYPTON y E2 [34]. Para procesadores de 64 bits los más 
veloces son Rijndael, Twofish, DFC [35], MARS y E2. Para 
el caso de implementaciones hardware, si bien es sumamente 
complejo de comparar unos con otros por la cantidad de 
variables constructivas a considerar [28], podemos anotar del 
mismo artículo que los mejores son CRYPTON, Serpent [36], 
Twofish, Rijndael y Safer+ [37]. 

Debido a que los concursos de selección del mejor cripto- 
sistema simétrico tanto en EEUU (NIST, 1.997-2.001, [26]), 
Europa (NESSIE, 2.000-2.003, [38]) y Japón (CRYPTREC, 
2.000-2.003, [39]) consideraron siempre al cifrado Rijndael 
como seleccionado en la serie finalista, podemos considerarlo 
como un candidato acertado en cuanto a seguridad e imple- 
mentación, y como hemos podido ver, también el mejor, en 
general, en referencia a la velocidad de cifrado. 

Anotemos, no obstante, que nos estamos moviendo dentro 
de los órdenes de magnitud de los cifrados simétricos de 
bloque, en las decenas y centenas de ciclos de reloj por byte 
cifrado, lo que supone un orden de 10-100 veces más de media 
de lo que podemos encontrar en los cifrados simétricos de 
“stream” o de flujo, que serán los que veremos en la siguiente 
sección, y que constituirán el núcleo más grueso de nuestro 
estudio, y de entre los cuales acabaremos eligiendo el mejor 
cifrado para condiciones extremas de velocidad. 


III. CRIPTOSISTEMAS SIMÉTRICOS DE FLUJO O DE 
“STREAM” 


Los cifrados de “stream” o de flujo son cifrados simétricos 
donde el texto claro se combina con la clave, expresada 
también como un flujo de bits, en general mezclada por la 
función xor. Este tipo de cifrado toma el texto claro y lo 


manipula bit a bit (o dígito a dígito, entendiendo “dígito” 
en sentido amplio) en cada momento, variando el cifrado en 
función del estado actual del sistema, por lo que también se 
denomina a este tipo de cifrado “cifrado de estados” (lo que 
no ocurre jamás en el cifrado en bloques, que es invariante). 
Intentan asemejarse al cifrado perfecto o de Vernam [40], 
consistente en un chorro de dígitos aleatorios combinado 
mediante xor con el texto claro, uno tras otro, el cual fue 
demostrado ser imposible de romper por Claude Shannon en 
el año 1.949 [41]. La dificultad en el uso de este sistema 
está en que la longitud de la clave secreta ha de ser tan 
larga como el texto a cifrar y que el generador aleatorio ha 
de serlo realmente. En la realidad los cifrados simétricos de 
flujo se adaptan a usar claves secretas menores que los de 
Vernam, como por ejemplo 128 bits pseudoaleatorios. Los 
criptosistemas de “stream” son más rápidos que los de bloques 
y presentan una menor complejidad cuando se implementan 
tanto en hardware -sobretodo- como en software. 

Nos centraremos en el siguiente listado -numeralmente muy 
amplio, lo que nos dará una completa idea de la realidad 
de este tipo de cifradores- de criptosistemas simétricos de 
flujo, sobre los que indicaremos su capacidad en eficiencia 
de velocidad cifrante de altas cantidades de datos: 

A5/l: 1.987 [42], AS/2: 1.989 [42], A5/3 (KASUMID): 
2.007 [43], BMGL: 2.001 [44], Chamaleon: 1.997 [45], 
Dragon: 2.005 [46], FISH: 1.993 [47], Grain: 2.004 [48], HC- 
128: 2.008 [49], HC-256: 2.004 [50], ISAAC: 1.996 [51], 
Leviathan: 2.000 [52], LILI-128: 2.000 [53], MICKEY: 
2.008 [54], MUGI: 2.002 [55], MULTI-s01: 2.002 [56], 
Panama: 1.998 [57], Phelix: 2.004 [58], Pike: 1.994 [59], 
Py: 2.005 [60], (TPy, TPypy y TPy6, 2.007, [61]), Rabbit: 
2.003 [62], RC4: 1.987 [63], RCR32/64: 2.007 [64], Salsa20: 
2.004 [65], Scream: 2.002 [66], SEAL: 1.994 ( [67], [68] ), 
SNOW: 2.000 [69], SOBER: 1.997 ( [70], [71] ), Sosemanuk: 
2.005 [72], Trivium: 2.005 [73], Turing: 2.003 [74], VEST: 
2.005 [75]. 

Muchos de ellos fueron presentados al concurso de 
cifradores de flujo convocados por Europa al descartar 
NESSIE en el año 2.003 a todos los cifradores presentados. 
Así pues, Europa creó le Proyecto eSTREAM [76], que entre 
los años 2.004 y 2.008 seleccionó en el perfil de hardware 
(para condiciones restrictivas de almacenamiento, potencia y 
espacio) los criptosistemas Grain v.1, MICKEY v.2 y Trivium. 
En el perfil de software los elegidos fueron HC-128, Rabbit, 
Salsa20/12 (es la versión Salsa 12 con 12 rondas) y Sose- 
manuk. Indiquemos que los cifradores de software tienden 
a ser más veloces que los de hardware, si bien cuando se 
implementan en software estos últimos resultan ser todavía 
más lentos que sus implementaciones hardware; siempre hay 
excepciones como Trivium (cifrador hardware), entre otros, 
comparativamente similar en velocidad a los más rápidos de 
los cifrados software ( [77], [73] ). 

Tras repasar la anterior lista de cifrados, si quitamos a la 
hora de optar por los que podrían sernos de interés, los orien- 
tados a hardware elegidos por eSTREAM (Grain, MICKEY, 
Trivium, VEST), los que son versiones anteriores de otros que 


los mejoran (SEAL) [66], los multicanales, que no es el caso 
que nos ocupa por no ser de propósito general (HC-128, HC- 
256), los que se usan para la protección de derechos de autor 
y usan de marcados, que lo ralentizan para nuestros propósitos 
(Chamaleon), y los que no son seguros, así considerados hoy 
en día (año 2.010), aunque a veces solamente a nivel teórico, 
(AS/1 ( [78], [79] ), AS5/2 [80], AS/3 [81], Dragon [82], 
FISH [59], Leviathan [83], LILI-128 [84], Phelix [85], Py 
( [86], [85] ), TPy ( [86], [87], [85], [88], [89] ), TPy6 
([90], [85] ), RC4 ( [91], [92] ), Trivium ( [93], [94], [95], [96] 
), Turing [97]), nuestra lista de los mejores representantes de 
cifrados de flujo, dando la referencia de la velocidad de cada 
uno de ellos, queda de la siguiente manera: 

BMGL ( [44], [52] ), ISAAC [98], MUGI [99], Multi- 
s01 [100], Panama [57], Pike [59], Rabbit [62], RCR-32 [64], 
RCR-64 [64], Salsa20/12 [101], Scream [66], SNOW2 [69], 
SOBER [102], Sosemanuk [72], TPypy [64]. 

Si ahora los clasificamos anotando su velocidad en ciclos de 
reloj por byte y si han sido o no elegidos en los dos Proyectos 
de cifradores de flujo, CRYPTREC o eSTREAM, tenemos el 
siguiente gráfico de la figura 1 y 2. 
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Fig. 1. Cifradores de flujo más rápidos existentes hoy en día. 
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Fig. 2. Representación comparativa de los cifradores mostrados en la Fig. 1. 


Si tomamos de la lista los mejor situados y analizamos 


además el Benchmarck del europeo ECRYPT II [103], pode- 
mos sacar algunas tablas adicionales de interés para nuestra 
búsqueda que ya nos dan valores de cifrado del entorno de los 
Gigabytes de datos por segundo, como muestra la figura 3. 
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IV. CONCLUSIONES 


De entre todos los cifradores simétricos, tanto de bloque 
como de flujo, recordar que los últimos son de orden de 10 
a 100 veces superiores en prestaciones de velocidad a los de 
bloque, aunque algunos de los más rápidos de entre éstos como 
Blowfish están en el orden de los 18 ciclos/byte [104], o AES- 
128 en modo CTR alcanza en el Opteron, como hemos visto 
en la figura 3, un valor de 9,86 ciclos/byte. 

No obstante, tras nuestro estudio, hemos de concluir que 
la elección final para cifradores simétricos -y cifradores de 
cualquier tipo, en definitiva, simétricos o asimétricos- está en 
usar cifradores de flujo o “stream”, tomando en cada caso 
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Fig. 3. Algunas tablas comparativas de los más rápidos cifradores en 


diferentes procesadores. 


particular, sobre la lista final mostrada en la figura 1, el que 
más se adecue a las características de procesador de la apli- 
cación considerada en cada escenario, con lo que obtendremos 
unos valores de cifrado del orden de los Gigabytes de datos 
por segundo en un ordenador usuario medio, cumpliendo de 
manera adecuada los requerimietos de poder cifrar cantidades 
enormes, del orden de los Gygabytes, en tiempos tan cortos 
como un segundo, algo impensable hace sólo 6 ó 8 años. 
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Resumen—En este artículo establecemos algunas propiedades 
de la forma normal algebraica de una función booleana a partir 
de su soporte y proponemos un método para determinar el grado 
de la misma a partir del soporte. 


I. INTRODUCCIÓN 


Las funciones booleanas se utilizan en distintas aplicaciones 
criptográficas tales como cifrado en bloque, cifrado en flujo y 
funciones hash [2], [4], [7], [9] y en teoría de códigos [3], [6], 
entre otras. Las propiedades más importantes de las funciones 
booleanas son la no linealidad, la inmunidad a la correlación 
y su grado. Por ejemplo, la implementación de una caja de 
sustitución O S-box necesita funciones booleanas no lineales 
que garanticen su efectividad criptográfica con el fin de resistir 
ataques tales como el criptoanálisis lineal o el criptoanálisis 
diferencial [1], [5], [8], [10]. 

Una de las exigencias más básica relativa a las funciones 
booleanas utilizadas en cifradores en flujo es que permitan 
incrementar la complejidad lineal [9], [15], [16], lo cual se 
consigue si éstas tienen un alto grado algebraico. 

La determinación completa de la forma normal algebraica 
de una función booleana de la que se conoce su tabla de 
verdad o su soporte requiere computar simultáneamente todos 
los coeficientes del polinomio correspondiente, pero si se desea 
conocer solamente el grado de la función, es posible reducir 
sustancialmente el número de operaciones necesarias mediante 
el algoritmo que presentamos aquí. 

El resto del artículo está organizado como sigue. En la sec- 
ción II introducimos algunos conceptos básicos y la notación 
que utilizaremos a lo largo del artículo y en la sección II 
introducimos los resultados principales del artículo; en particu- 
lar, introducimos una serie de propiedades que nos permitirán 
determinar el grado de una función booleana de n variables a 
partir de su soporte. Finalizamos con las conclusiones y líneas 
futuras en la sección IV. 


TI. PRELIMINARES 


Denotamos por FF> el cuerpo de Galois de dos elementos 
0 y 1 con la adición (denotada por $) y la multiplicación 
(denotada por yuxtaposición). Para cada entero positivo n, es 
bien conocido que FS es un espacio vectorial de dimensión 
n sobre Faz con la adición usual (denotada también por $). 
Denotamos por Env(u¡,uz,...,ux) el subespacio vectorial 
de IF) generado por los vectores U4],uz,...,Uz E F3. Si 
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u = (u¡,uz,...,U,) € E3, llamamos peso de u, y escribimos 
w(u), al número de componentes iguales a 1 y si consideramos 
0 y 1 como elementos de Z, claramente 1w(u) = >, uz. Si 
para ¿ = 0,1,2,...,2” — 1, denotamos por 2 la expansión 
binaria de ¿ de n dígitos, entonces FF =(¿|0<:¿<2"—1). 
Una función booleana de n variables es una aplicación 
f : F5 —> F>. Denotamos por B,, el conjunto de todas las 
funciones booleanas de n variables; es bien conocido que B,,, 
con la adición usual de funciones (que seguimos denotando 
por $), es un espacio vectorial de dimensión 2” sobre Fa. 
Si f € Bn, llamamos tabla de verdad de f (véase, por 
ejemplo [11], [12]) a la secuencia binaria de longitud 2” dada 


por 
Es =(£(0),£(0),...,£Q” 0): 


Llamamos soporte de f, y escribimos Sop (f), al conjunto de 
vectores de FS cuya imagen por f es 1, es decir 


Sop (f) = ta € Fz | f(a) =1). 


Si f € B,,, llamamos peso de f, y escribimos w(f), al número 
de 1 de la tabla de verdad de f, por tanto, w(f) = [Sop (f)| 
y Claramente 


w(f) = Y fa). 


acer 


Decimos que f es equilibrada si w(f) = 2"! 

Obviamente f es la función nula si y sólo si Sop (f) = () y 
entonces w(f) = 0. Análogamente f es la función constante 1 
si y sólo si Sop (f) = F3 y en tal caso w(f) = 2”. 

Es fácil comprobar que si f, y € B,,, entonces 


Sop (f O 9) = Sop (f) ASop (y) 


donde A denota de diferencia simétrica de conjuntos y, en 
consecuencia, 


w(f0 9) =w(f) + w(9) (mod 2). 
En general, si f; € B,,, para ¿ =1,2,...,m, entonces 
Sop SD fi |] = ASop(45) (1) 
J= 


y, por tanto, 


aw Dd fi 
j=1 


m 


= S wtf) (mod 2). 


j=1 


Supongamos ahora que  = (11,12,...,%,) donde cada 
xj, para  =1,2,...,n, es una variable binaria. Si f € B,, 
podemos escribir f(x) de forma única (véase, por ejemplo, 
[6], [11], [12], [13], [14]) como 


f()= O (ur (2) 


uEr; 


donde uf(u) € F> y si u= (u¡,usz,..., Un), entonces 


Ur ua Un siuj=1, 


AS L; 

2 =4x2...q con a =¿ 0" 
pl 2 n 6] A 

1, siu¿=0. 


La expresión (2), en la que cada uno de los términos x“ es un 
monomio cuyo grado es w(u), se conoce con el nombre de 
forma normal algebraica (FNA) de f(x). Llamamos grado 
de f, y escribimos gr(f), al mayor de los grados de los 
monomios de su FNA, es decir 


gr(f) = max(w(u) | py(u) =1). 


Decimos que f es una función afín si gr (f) = 1; en tal 
caso, la FNA de f es 


f (a) = a 0 4,11 D 42220: D AnTn 


con az € Fa, para ¿ = 0,1,2,...,n. En particular, si ag = 0, 

decimos que f es una función lineal. Es fácil probar que toda 

función afín es equilibrada, aunque el recíproco no es cierto. 
Por otro lado, si 


entonces (véase por ejemplo [13])) 
ps = EsAn 
donde 
An-—1 An-—1 
= > = 
Án | o ds | paran >1, con Ay = [1]. 
Ahora, si 


“> Un) 


=u12 19427 ?09---Qun-120 Uunl 


u= (uz, ua, . . 


y E(u) = Env [u127=1, 43272, ...,4n-12,4n1), enton- 
ces es fácil probar por inducción sobre n, que 


uju)= E) fa). 3) 


acE(u) 


TII. RESULTADOS PRINCIPALES 


En todo este artículo denotamos por S,,, como es habitual, 
el conjunto formado por las permutaciones de (1,2,...,n). 
Además, si 0 € S,, == (11,%2,...,%n) E FF, MCZ3 y 
f € B,,, escribimos 2” = (21), DAD a) : 


M'=[0" | neM) y f%0)=$(0"). 


El resultado siguiente, cuya demostración es inmediata, esta- 
blece la relación entre Sop (£%) y Sop (f) para todo o € S,,. 


Teorema 1: Supongamos que d € S,,. Si f € B,,, entonces 


Sop (4%) = (Sop (1) 
y, en consecuencia, w(f%) =w(f). 


El resultado siguiente, cuya demostración también es inme- 
diata, permite determinar, de forma explícita, el soporte y, por 
tanto, el peso, de cualquier monomio. 


Teorema 2: Supongamos que 1< í¡ <i9<-+**<ip <Nn y 
consideremos d € S, tal que 0(j) =1;, para j =1,2,...,k. 
Si f(2) =2x;,%i, "Ti, y u=(1,1,...,1) € FÉ, entonces 


(Sop (£))” = (Lu) x E37* (4) 


y, en particular, w(f) =2""*, 


Una consecuencia inmediata del resultado anterior es que el 
peso del monomio formado por todas las variables (es decir, 
cuando k = n) es 1, mientras que el peso de cualquier otro 
monomio es una potencia de 2 y, por tanto, un número par. 

Otra consecuencia inmediata del teorema 2 es que si el 
grado de una función booleana de n variables es menor o igual 
que n— 2, entonces la suma de los elementos de su soporte es 
el vector nulo. Antes, sin embargo, introducimos el siguiente 
lema técnico que nos permitirá simplificar la demostración de 
dicho resultado. 


Lema 1: Supongamos que 1< ii < ig <-**< ip < n. Si 
Fx) ==; Ti, "Ti, y 1LEk <n—2, entonces 


Dd a=0. 


aesop(f) 
Demostración: Supongamos que u = (1,1,...,1) € Ff. 
Claramente 
D «- 9 (uo 
actíupxF37* Wer o+ 
E Du .) = (040,4) =0 
Wer PO? werjo* 


ya que cada una de las componentes de los vectores 
Doer-* UY Ouepr-* v es la suma de un número par de 1. 

El resultado se sigue ahora del hecho de que si consideramos 
0 € S, tal que 0(j) =1;, para ¿ =1,2,...,k, entonces, por 
el teorema 2, los elementos de Sop (f) se obtienen a partir de 
los elementos de [u) x F37* permutando sus componentes 
de acuerdo con la permutación 07! m 


Notemos que la condición 1 < k < n— 2 del lema anterior 
es necesaria, ya que si k = n, entonces 


Sop (f) = tuj € Ez 


mientras que si k =n—1, y f(x) es el monomio de grado n—1 
que no contiene la variable x;, entonces, por el teorema 2, 


Sop (f) = [u, u;j) 


y claramente ud u; 40. 


con u¿=ug2"” 7? 


Teorema 3: Si f € B, y gr(f) <n—2, entonces 


Demostración: Supongamos que 
(2) = O file) 
j=1 


con f;(x), para j =1,2,...,m, un monomio de grado menor 
o igual que n — 2. 

Procederemos por inducción sobre m. Para m = 
resultado es cierto por el lema 1. 

Supongamos que el resultado es cierto para m—1 y veamos 
que también lo es para m. Notemos en primer lugar que 


l el 


m-—1 


Sop (f) = A Sop (f,) = (A s0n(5) ASOP (fm) - 


Por comodidad en la notación, sean 


m-—1 


A=Sop(f), B= Á Sop(4;) y C=Sop(fm). 


De las propiedades de la unión, intersección y diferencia 
simétrica de conjuntos tenemos, por la hipótesis de inducción, 


o=Hb= BH bye YO a 
bEB bEANB deBno 
y, por el lema 1, 
0 = Dd c= Dd co DD e. 
(18) cEANA«a eeEBNO 


Ahora, sumando las dos expresiones anteriores, 


0 = ae bo an c= Ha 


bEANB cEANno—o acA 
ya que 
Dd do Dd e=0. 
deBnC eeBnCO 


ll 
El recíproco del teorema anterior no es cierto en general. 
Sin embargo, antes de poder establecer bajo qué condiciones 
es cierto dicho recíproco, necesitamos introducir algunos re- 
sultados. 
Otra consecuencia inmediata que se deduce del teorema 2 
es que el grado de f € B,, es n si y sólo si w(.f) es un número 
impar, tal como establecemos en el resultado siguiente. 


Teorema 4: Si f € B,,, entonces gr (f) =n si y sólo si w(f) 
es un número impar. 


Demostración: Claramente f = g 9 h, con g,h € B,, 
tales que 


er(g)<n—=1 y h(x)=ax,t2:-*x, con a € Za. 


Notemos que w(h) = a y que gr(f) =n si y sólo si a = 1. 

Además, si g(1) = O)_, 9(2), con g;(w) un monomio 
tal que gr (9¿) <n— 1, para j = 1,2,...,m, entonces, por 
la expresión (1) y el teorema 2 tenemos que 


w(f) = Y w(g;) + w(h) (mod 2) =a (mod 2) 
j=1 
y así, gr(f) =n si y sólo si w(f) es impar. m 
Este resultado permite probar, como habíamos anunciado 
antes, que el recíproco del teorema 3 no es cierto. 
Ejemplo 1: Si f € B3 y Sop(f) = [3,5,6), por el teore- 
ma 4 tenemos que gr (f) = 3 y sin embargo 30506 =0. 


El resultado siguiente pone de manifiesto que la situación 
que describe el ejemplo anterior sólo se puede presentar 
cuando |Sop (f)| es impar, es decir, cuando gr (f) = m. 


Teorema 5: Supongamos que f € B,, tal que |Sop (f)| es un 


número par. Si 
D ao 
aESop(f) 


entonces 1< gr(f) <n-—2. 


Demostración: Como |Sop (£)| es par, por el teorema 4, 
tenemos que gr (f) <n— 1. 
Sigr(f) =n-— 1, entonces f tiene al menos un monomio 
de grado n — 1. Supongamos que 


con g;(1), para j =1,2,...,m, un monomio de grado n— 1 
que no contiene la variable x,, y que gr (h) <n— 2. 

Procediendo como en la demostración del teorema 3, tenien- 
do en cuenta que por el teorema 3, Daeesortis a = 0, y de 
acuerdo con el comentario que precede al teorema 3, tenemos 
que 


Did Da 


0 = 
ageSop(f) j=1 aEsSop(g;) agSop(h) 

m 
DD agro, si m es par, 

Ji 

=> m 
ub Dd 2" *5,  simoes impar 

j=1 
que es una contradicción. Por tanto, gr (f) <n— 2. a 


Así, como consecuencia inmediata de los teoremas 3 y 5 
tenemos el siguiente resultado. 


Corolario 1: Sea f € B,, tal que |[Sop (f)| es un número par. 
Entonces gr(f) <n—2 si y sólo si 


Dd a =0. 
acesSop(f) 


Antes de continuar, veamos cómo podemos utilizar los 
resultados vistos hasta ahora para obtener el grado de una 
función booleana a partir de su soporte. 


Ejemplo 2: Sea f € Ba tal que 
Sop (f) = (0,5,6,7,9,10,11,13,14,15). 
Puesto que |Sop (f)| = 10 es un número par y 
0065669579909 100 119130 14015=0 


por el corolario 1 tenemos que gr (f) <4-2=2, 
Por otro lado, como w(f) = [Sop (f)| 4 8, tenemos que 

F(x) no es equilibrada y, por tanto, f(x) no es lineal ni afín. 

Como tampoco es constante, necesariamente, gr (f) > 1. 
En consecuencia, gr (f) = 2. 


Como acabamos de ver, es posible determinar el grado 
de una función booleana f € B,, a partir de su soporte 
sin necesidad de conocer su FNA. Veremos seguidamente 
que, es posible también determinar, de forma sencilla, si un 
determinado monomio forma parte de la FNA de f. 

Sea f € B,, y supongamos que conocemos Sop (f). Puesto 
que w(f) = |Sop (f)| el teorema 4 permite afirmar que en 
la FNA de f(x) está el monomio 1,12:-*2, si y sólo si 
[Sop (£)| es un número impar. El teorema siguiente establece 
una condición necesaria y suficiente para que la FNA de f(x) 
contenga cualquier monomio de grado k con 1< k< mn. 
Antes, sin embargo, necesitamos el resultado siguiente que 
facilitará la demostración de dicho teorema. 


Lema 2: Supongamos que l < ií < ig <***< tp < mn 
y consideremos la aplicación FE => F2 dada por 
pl(Y1, Ya, pal , Yk) = (21, Ta, ... sii) con 
0, silg fir, da,..., tr), 
Ey = 

; Yi, Ssil=13j, para j =1,2,...,k. 
Si f € B, y consideramos h € Bj, tal que 

h(y1, Ya, ... Yu) = Holy1, ya, EE! Yr)), 


entonces 
[Sop (h)| = |Sop (A) n Env o asi pet , 


Demostración: Notemos en primer lugar que p es un 
monomorfismo de espacios vectoriales y que Im(«) 
Env >. y y 

Si u € Sop (h), entonces 1 = h(u) = f(p(u)) con lo que 
p(u) € Sop (f) y como claramente y(u) € Im(p), tenemos 
que p(u) € Sop(f)NEnv(27-+,2n=%,.., 2n=+). por 
tanto, 


p(Sop (h)) € Sop(f)NEnv(27%, 29%, .,. 2nel, 


10 


Supongamos ahora que 


., Un) 
Esp AMER27% 2eo,.. ae 


v = (u1,v,.. 
entonces f(v) =1 y uv; =0sil E [i1,12,...,0x). Claramente 
.,04) EF¿ y ¿(u)=0, 


por tanto h(u) = f(p(u)) = f(v) = 1, con lo que u € 
Sop (h) y así v = p(u) e p(Sop (h)). En consecuencia 


Sep mEnr (2%, 2%=%.... 2881 E elSop(h)): 


u= (uv, v2,.. 


De esta inclusión y de la anterior tenemos que 
p(Sop(A)) =Sop(f)MEnvJ29-%, 29%, ... 2n=*eL. 


El resultado se sigue ahora del hecho de que |p(Sop (h))| = 
[Sop (h)| por ser y inyectiva. a 


Teorema 6: Supongamos que conocemos Sop (f) para f € 
B,,. La ENA de f(x) contiene el monomio X;,%¡, *** Y;j, CON 
1<k<mnm si y sólo si 


[Sop (f) N Env (294,298, ... 2rote) | 


k 


es un número impar. 


Demostración: Con la notación del lema 2 tenemos que 
la FNA de f(x) contiene el monomio 2;,%;,***U¡, Si y 
sólo si la FNA de h(y) contiene el monomio yiYa :**Yk. 
Ahora bien, por el teorema 4, la FNA de h(y) con- 
tiene el monomio yiy2-:*Yx si y sólo si |Sop(h)| es 
un número impar. Finalmente, por el lema 2, la FNA 
de f(x) contiene el monomio 2;,;,***1¿, Si y sólo si 
[Sop (A) N Env cd 0 y es un número 
impar. L 
Notemos que el teorema anterior permite afirmar que 
er(f) > k si y sólo si existen k números enteros tales que 
1<7% <td <:""<t; <n y 


¡Sopl ME 2 2 
es un número impar, o equivalentemente, 
pp(u) = [Sop (f) N Env A db a mod 2 
., Un ) € F% con 


sil É Paslare Us 
, Sil=145, paraj=1,2,...,k. 


para u = (u¡,uz,.. 


»- 


Aplicando sucesivamente el resultado anterior, podemos 
determinar tanto el grado como la FNA de una función 
booleana de la que conocemos su soporte. El ejemplo siguiente 
nos ayudará a entender este proceso. 


0, 
1 


Ejemplo 3: Consideremos de nuevo la función f € Ba del 

ejemplo 2. Hemos visto en dicho ejemplo que gr (f) = 2. Si 

queremos obtener la FNA de f(x), necesitamos saber cuáles 

son los monomios de grado 2 y de grado 1 que contiene. 
Los posibles monomios de grado 2 son 


1112, TiTzg, Tila, Talz, Tala y Tala. 


Que alguno de dichos monomios esté en la FNA de f(x) 
depende, de acuerdo con el teorema 6, de que alguno de los 
cardinales de los conjuntos 


S, =Sop (f) NEnv(2%*, 2-2), 

S2 = Sop(f) N Env aa a A 

S3 = Sop (f) MN Env 29. A ' 

Sa = Sop(f) N Env (292, 2 a 

Si  = Sop (f) N Env p2r., sq ' 

Sé = Sop (f) N Env e, are ; 

sea impar. Puesto que 

S¡=(0), S2=(0,10), S¿=(0,9), 
Sa = (10,6), 55 = (0,5) y S6= 10), 


podemos afirmar que la FNA de f(x) contiene los monomios 
1112 Y Lzla. 

Para determinar los monomios de grado 1 de la FNA de x 
procedemos de la misma forma. Puesto que 


Sop (f) N Env (21) = (0), Sop(f) N Env [2t=2) = (0), 
Sop (f) N Env (23) = (0), Sop(f) N Env (29) = (0), 


tenemos, de acuerdo con el teorema 6, que los monomios 21, 
23, Y3 y Y4 forman parte de la FNA de f(x). 

Finalmente, como O € Sop(f), tenemos que el término 
constante 1, forma parte de la FNA de f(x). 

En consecuencia, la FNA de f(x) es 


f(a)=16 


Como acabamos de ver en el ejemplo anterior, para deter- 
minar completamente la FNA de f(x) a partir de Sop (f) 
necesitamos calcular el cardinal de una serie de conjuntos 
obtenidos a partir de Sop (f), por lo que el procedimiento, 
en general, no constituye de por sí un algoritmo eficiente. 

Sin embargo, si 1 < k < mn, mediante un razonamiento 
análogo al seguido para obtener la expresión (3), podemos 
separar las n variables en dos conjuntos formados por k y 
n — k variables, respectivamente, tal como describimos en el 
resultado siguiente. La demostración es fácil pero larga y, por 
tanto, la omitimos. 


La O T1T2 0 Tala. 


Teorema 7: Supongamos que f € B,,. Sil <k < n entonces 
-9 (89 no)o 


ber MaEE(b) 
donde f. € By, para a € FE, satisface f(x) = f(a,x). 


Además, 


El resultado siguiente, cuya demostración es inmediata, 
establece la relación entre Sop(f) y Sop (fa), para todo 
a € FI. 


F(y, z) 


er (f) = max 
berFh 


a fa | +w(b) 


acE(b) 
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Teorema 8: Con la notación del teorema 7, 


Sop (fa) = fv € F3"* | (a,v) € Sop (1) 


BD fa 


acE(b) 


Sop op (fa). 


E A, 
Antes de continuar, veamos un ejemplo que nos ayudará a 
entender el proceso a seguir. 
Ejemplo 4: Sea f € Bs tal que 
Sop (f) 
= (6,7,12,13,16,17,18,20, 21, 23, 24, 25, 26, 30). 
Puesto que [Sop (f)| es par y 


17 
24 


6057061209 13016 
9 20 9 21 9 23 


18 
2509260930=0 


por el corolario 1, tenemos que gr (f) <5-2=3. 
Ahora, de acuerdo con el teorema 7, tenemos que 


gr (f) = max(er (fo), gr (fo 9 f1) +1) 
con fo, fi € Ba tales que 


F(0,%2, Ta, Ta, 05), 
FL, To, 03, La, 26), 


folt2, 13, Ta, U5) = 

Fi(u2, 23, Ta, 25) NN 
y por el teorema 8, 

Sop (fo) == (6, 7, 12, 13) 

Sop (f1) = (0,1,2,4,5,7,8,9,10,14). 
Por tanto 


Sop (fo 9 f1) = Sop (fo) ASop (f1) 
=(0,1,2,4,5,6,8,9,10,12,13,14). 


Además, como 697912913=0 y 


00109204050608 
$9061009120913014=0 


por el corolario 1 tenemos que 
gr(f) £4-2=2 y egr(f00f)<4-2=2 
y así gr (f) < max(2,2 +1] =3. 
Ahora, de nuevo por el teorema 7 tenemos que 
gr (f) = max(gr (fo), gr (fo 9 f1) +1, 
gr (fo O f2) + 1, gr (fo € 
con fo, f1, f2, f3 € B3 tales que 
= f(0, 0, 23, 24, 25), 
F(0, 1,23, Ta, T T5 
=f(, 
(1, 


F(1,1,23, La, 5 


f0f0f)+2) 


fo(u3, ta, 25) 
L3, T4, U5 


) 
fil ), 
folx3, ta, 25 1,0, 23, 24, U5), 
( ) 


f3 23, T4, U5 


Jj 
) 
pS 


y, por el teorema 8, 


Sop (fo) == (6, 7), Sop (f1) > (4, 5) 
Sop (f2) = (0, 1,2,4, 5,7) y Sop (f3) = (0, 1, 2,6) 


con lo que 


Sop (fo D f1) = Sop (fo) ASop (f1) > (4,5, 6,7) 
Sop (fo D f2) = Sop (fo) ASop (f2) = (0, 1,2, 4,5, 6) 


Sop (fo 0 f1 0 f2 0 f3) 
= Sop (fo) A Sop (f1) ASop (f2) ASop (f3) =0 


Además, como 6967=1%0, 40659607=0 y 


001020405096=4H0 


por el corolario 1 tenemos que 
gr(f0)=2, gr(fO0f)<1, gr(fo0O fa) =2 


y fo9f0f0 f3 =0, con lo que er (f) = 3. 


Los resultados anteriores permiten establecer el algoritmo 
siguiente para determinar el grado de cualquier f € B,, a partir 
de Sop (f). 

Algoritmo: Obtención de gr (f), para f € B,,, a partir de 
Sop (+). 


1) Si [Sop (f)| es impar, entonces gr (f) = nm. 
2) En otro caso, sea s = Dacsop(f) a. 
3) Si s 4 0, entonces gr(f) =n— 1. 
4) En otro caso, sea maxgr (f) =m— 2 el máximo valor 
que puede tomar gr (f) y suponer que k = 1. 
a) Para b € FI: 
1) Obtener gy = Daerz(o) Tos 
1) Si [Sop (gp)| es impar, entonces gr (ga) =n — 
k. 
111) En otro caso, sea sp = ctra) a. 
iv) Si sy % 0, entonces gr (ga) =n—k-— 1. En 
otro caso, gr (gs) <nN—k-— 2. 
b) Si maxgr (f) = maxaces (er (99) +10(b)), el pro- 
ceso termina y gr (f) = maxgr (f). En otro caso, 


hacer maxgr(f) = maxpens ler (90) + w()), 
aumentar k en una unidad e ir al paso 4a). 


TV. CONCLUSIONES Y LINEAS FUTURAS 


En este artículo presentamos una serie de propiedades de 
una función booleana que relacionan el soporte y la FNA de 
la misma. Estas propiedades nos han permitido establecer un 
algoritmo para determinar el grado de una función booleana 
cuando conocemos el soporte de la misma (y obviamente no 
conocemos su FNA). En un trabajo futuro abordaremos los 
aspectos computacionales del algoritmo propuesto. 
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Resumen—Utilizando una base de F> (con n un número par) 
y la matriz asociada de un polinomio primitivo de grado n/2 y 
coeficientes en F>, construimos los soportes de algunas funciones 
bent de n variables. 


I. INTRODUCCIÓN 


Las funciones booleanas se utilizan en distintas aplicacio- 
nes criptográficas tales como cifrado en bloque, cifrado en 
flujo y funciones hash [5], [10], [18], [23]. Por ejemplo, la 
implementación de una caja de sustitución o S-box necesita 
funciones booleanas no lineales para resistir ataques tales 
como el criptoanálisis lineal o el criptoanálisis diferencial [3], 
[16], [21], [25]. 

Para un número par de variables, las funciones booleanas 
de máxima no linealidad son las llamadas funciones bent [11], 
[29], [31]. El nombre bent para dichas funciones se debe 
a Rothaus [28], aunque su origen se remonta a un artículo 
de McFarland [22] sobre conjuntos de diferencias en grupos 
no cíclicos; posteriormente Dillon [12] sistematizó y extendió 
las ideas de McFarland proporcionando una gran cantidad de 
propiedades. Desde entonces estas funciones han sido objeto 
de un intenso estudio como se desprende de la abundante 
literatura al respecto (véase por ejemplo [1], [2], [4], [6], [8], 
[9], [14], [15], [17], [19], [24], [26] y las referencias en ellas 
incluidas). 

En estos momentos, se desconoce la existencia de un 
método que permita obtener todas las funciones bent y so- 
lamente se conoce su número para algunos casos particulares 
(n = 2,4,6,8 con n el número de variables); la clasificación, 
y por tanto el número de tales funciones, para n > 8 continúa 
siendo un problema abierto. 

Hay muchos métodos para construir funciones bent [7], 
[12], [13], [17], [22], [25], [28] los cuales han dado lugar a di- 
ferentes clases de funciones: Maiorana-McFarland, Rothauss, 
Partial Spread (PS), etc. En este artículo nos centramos en la 
construcción de funciones bent que pertenecen a la clase PS. 

El resto del artículo está organizado de la siguiente manera: 
En la sección Il, introducimos algunas definiciones básicas y 
la notación utilizada. En la sección III, presentamos un método 
general para caracterizar la construcción de funciones bent de 
n variables (con n un número par) de la clase PS utilizando 
una base de F% y un polinomio primitivo de grado n/2 
en F2[X]. En la sección IV, introducimos un procedimiento 
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práctico para la obtención del soporte de una función bent del 
tipo PS, mostrando algunos ejemplos; además establecemos 
el número de dichos soportes que podemos construir con una 
base y un polinomio primitivo fijo; dicho número constituye, 
en definitiva, una cota inferior del número de funciones bent 
de n variables. Finalmente, en la sección V, presentamos 
algunos problemas abiertos relacionados con la construcción 
introducida en este artículo. 


TI. PRELIMINARES 


Sea Fa el cuerpo binario con la adición denotada por Y y 
la multiplicación denotada por yuxtaposición. Para cualquier 
entero positivo n, es bien conocido que JF% es un espacio 
vectorial sobre 3 con la adición usual (denotada también 
por €). Para una matriz cualquiera A de tamaño n x k con 
elementos en F2, denotamos por col (4) el espacio columna de 
A; por tanto, col (4) es un subespacio vectorial de F%. En este 
artículo, los vectores de IF son vectores columna. Recordemos 
que la matriz de control de paridad H del [2* — 1, k]-código 
binario de Hamming es la matriz cuya ¿-ésima columna de k 
dígitos del entero ¿ paral <1< 2* —1 (véase [27]); por tanto, 
es evidente que los vectores de col (4) son las columnas de 
la matriz AH. 

Una función booleana de n variables es una aplicación 
f : F3 — F3. El conjunto de todas las funciones booleanas 
de n variables se denota por B,, y es un espacio vectorial con 
la adición (denotada también por £) de dimensión 2” sobre 
F2. Para f € B,,, llamamos soporte de f al conjunto 


Sop (f) = ta EF) | f(a) =1). 


El peso de Hamming de f € B,,, que denotamos por w(f), 
es el cardinal de Sop (f). 
Decimos que f € B,, es una función afín si 


f(x) = (a, 2) 0D, 


donde a € F3, b € Fa y (a, x) es el producto escalar usual de 
los vectores a y x. Si b= 0, decimos que f es una función 
lineal. 

Definimos la no linealidad de una función f € B,, como 


NL(f) = mintd(f, p) | p € Any 


donde A, es el conjunto de todas las funciones afines y la 
distancia d(f, g) entre dos funciones booleanas f,g € B,, se 


define como d(f, gy) = w(f € g). La no linealidad de f está 
acotada superiormente (véase [31]) por 


NL) <*"=asl 


Llamamos funciones bent a las funciones booleanas que 
alcanzan la máxima no linealidad (véase [31]). Por tanto, las 
funciones bent solamente existen para n par. 

Finalmente, es bien conocido (véase por ejemplo [30]) que 
si f(x) es una función bent, entonces su función complemen- 
taria, 10 f(x), es también una función bent. 

A partir de ahora suponemos que n = 2k y nos centramos 
en la obtención de funciones bent de la clase PS. El teorema 
siguiente, al que haremos referencia en diversas ocasiones, 
introduce dicha clase de funciones bent (véase [12]). 


Teorema 1: Supongamos que G¡,G2,...,G¿ son subespa- 
cios vectoriales de F5 de dimensión k tales que G¡NG; = (0) 
para i,j=1,2,...,t con 1H j, y consideremos el conjunto 


t 
* 
UG, 
i=1 


tb 
fopul)E:, $ t=2141, 
1=1 


si t=2%k1, 


B= 


con Gí = G¡1 (0). Entonces B es el soporte de una función 
bent de n variables. 


Dillon [12] denotó por PS” (respectivamente, PS*), la 
clase de funciones bent para la que + = 2*=1 (respectivamente, 
1=214 1D. 

Ahora, construimos funciones bent basadas en la clase PS 
utilizando los complementos ortogonales de los subespacios 
vectoriales en lugar de los propios subespacios. Pero primero 
recordemos que el complemento ortogonal de un subespacio 
vectorial G de F%, denotado por G>, es el subespacio vectorial 


G! =(y € F3 | (2, y) =0, para todo x € G). 


El siguiente resultado, cuya demostración se puede en- 
contrar en cualquier libro de álgebra lineal, será necesario 
para probar el corolario 1, el cual establece que los comple- 
mentos ortogonales de los subespacios vectoriales satisfacen 
las condiciones necesarias para que los soportes que definen 
correspondan a funciones bent de la clase PS. 


Lema 1: Si G y H son dos subespacios vectoriales de 3 
tales que GN H =¿(0) y dim G = dim A = k, entonces 


G+nA*+=(0) y dimG* = dim HA? =k. 


Ahora, como consecuencia inmediata del lema anterior, 
tenemos el siguiente resultado. 


Corolario 1: Sean G,,Ga2,..., G;¿ subespacios vectoriales de 
F5 de dimensión k, tales que GN G; = (0) para i,j = 


14 


1,2,...,t con 14H j. Entonces, 


si t=241, 


BD -—¿i y 
[opul) (GH, si t=2*1+1, 
i=1 
Demostración: Para i¡=1,2,...,2'71 4 1 tenemos que 


dim GF =n-— dimG; = k. 
Además, si = € G;+ n G5, entonces 


(2, u) =(2,v) =0, para todo u € G;,v € G), 


es decir, 
(1,uSv) =0, para todo u € G,,v € G,, 
y por el lema 1, 
(x,w)=0, para todo w € F>. 


Por tanto, a: = O y, en consecuencia G NG7 = (0). 
Ahora, por el teorema 1 tenemos que B(-) es el soporte de 
una función bent de n variables. m 


TII. RESULTADOS PRINCIPALES 


Ya estamos en condiciones de construir, de forma explícita, 
los subespacios G; del teorema 1. Para ello, primero consi- 
deramos algunas bases del espacio columna de las matrices 
obtenidas a partir de dos matrices de tamaño n Xx k con 
coeficientes en F2 y cuyo rango es k; y la matriz asociada 
a un polinomio primitivo de grado k en F2[X]. 

La demostración del siguiente lema es directa y por ello la 
omitimos. 


Lema 2: Supongamos que C es la matriz asociada al poli- 
nomio primitivo 


Co + aX +40X? 4 + cg 1 XP" 14 XP € Fo[X]. 
Supongamos también que la matriz U = [uy ur uy] 
de tamaño n X k tiene rango k, y consideremos, para j = 
1,2,...,2 — 2, el vector 

Uj+k = CQUj OD CUj¿ 1 DOC 18541 € Ez. 
Entonces, para i=1,2,...,2* — 1, 

UCH*= [uz Upa Ui+h-1] 
col (U) = col (UC*?). 
Notemos que como consecuencia de este resultado, tenemos 
que 
rg (UC””) =k, parai=1,2,...,2—1 
y, por tanto, las columnas de la matriz UC*=* constituyen 
también una base de col (0). 


El teorema siguiente nos permite construir una familia de 
subespacios G, que satisfacen las condiciones del teorema 1. 


Teorema 2: Sean U y V matrices de tamaño n x k tales 
que [U v] es invertible y supongamos que C es la matriz 
asociada a un polinomio primitivo de grado k en F2[X]. Si 


Go = col (V), Ear = col (U) y 


G, =col(UC** 8 V), parai=1,2,...,2* —1, 


entonces dimG, = k, y G,-NMG, = (0) para r,s = 
0,1,2,...P conrás. 


Demostración: Claramente rg (U) = rg(V) = k. Por 
tanto, dim Gy = dim Gar = É. 
Si dim G; < k para algún ¿€ (1,2,...,2* — 1), entonces, 
existe a € FEA (0) tal que 


(UC?!*ev)a=UC*la9Va=0 


pero esto es una contradicción ya que las columnas de la 
matriz [U gal v] forman una base de IFy de acuerdo con la 
elección de las matrices U y V y el lema 2. En consecuencia, 
dimG, =k para i=1,2,...,2-—1, 

Evidentemente, Goy N Gar = (0). 

Supongamos en primer lugar que w € Gy NG; para algún 
¿€ [1,2,3,..., 2-11). Entonces, de acuerdo con el lema 2 


w=(UC**9V) a y w=Vb 


para algunos a, b € FS. Por tanto, 


UC*lagV(aob)=0 (1) 


y otra vez, como las columnas de la matriz [U ql v] 
forman una base de IF5, de la expresión (1) podemos decir 
que 
a=0 y asb=0; 
así que, b= 0 con lo que w = 0. Por tanto, Gy NG; = (0) 
para ¿€ (1,2,3,...,2-—1). 
Supongamos ahora que w € G¿NG; para algunos 1, j tales 


quel<13<j< 2* —1. Procediendo como en el caso anterior, 
tenemos que 


w=(UC** eV) a=(UCI* 9 V)b, (2) 
por tanto, de acuerdo con el lema 2, tenemos que 
0=(UC**9V)ao (UC? * 9 V)b 
=Ud0 V (a 9 b) 


para algún d € F%. Sin embargo, como las columnas de la 
matriz [U v] forman una base de F%, necesariamente 


d=aobb=0. 


En particular, a 
obtenemos que 


b y, sustituyendo en la expresión (2), 


UC la =UCI a 


y, por tanto, (CÍ7*89 I) a =0 ya que rg (U) =kei< j. 
Ahora, como C es la matriz asociada a un polinomio primitivo 
de grado k y Fax es isomorfo a F>2[C] (véase [20]), podemos 
afirmar que la matriz CI7iG 1 es invertible y, en consecuencia, 
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a = 0. Por tanto, sustituyendo dicho valor en la expresión (2), 
tenemos que w=0 y así, G¿N G;= 40). 

Finalmente, supongamos que w € Gax NG; para algún 
¡€ [1,2,3,...,2* — 1). Entonces, procediendo como en el 
caso anterior, tenemos que 


(3) 


para algunos a, b € F%. Por tanto, de acuerdo con el lema 2, 
tenemos que 


w=Ub y w=(UC**9V) a, 


0=(UC**9V)asUb=UdOVa 


para algún d € F%. Otra vez, como las columnas de la matriz 
[U v] forman una base de FF, necesariamente d = a =0, 
y, sustituyendo en la expresión (3), obtenemos que w = O. 
Por tanto, Goy+ MG; = (0) para ¿=1,2,...,2F—1,. m 

En el teorema 2, podríamos haber considerado también los 
subespacios vectoriales 


F, = col (U 9 VC?*) para ¿=1,2,...,24—1, 


ya que satisfacen todas las condiciones necesarias siempre que 
¡+3 4 2" +1. Sin embargo, esto no es posible ya que cada uno 
de estos subespacios coincide con alguno de los subespacios 
G; definidos en dicho teorema, como ponemos de manifiesto 
en el siguiente resultado. 


Teorema 3: Sean U y V matrices de tamaño n x k tales 
que [U v] es invertible, supongamos que C' es la matriz 
asociada a un polinomio primitivo de grado k en Fa[X] y 
consideremos, para i,j € $1,2,...,2* — 1), los subespacios 
vectoriales 


G;¡=col(UC?**9V) y Fj¡=col(USVCI”). 


Entonces para todo i € 41,2,...,2* — 1) existe un único 
jEef1,2,...,2* —1) tal que G; = F;. 


Demostración: Claramente PF, =G. 
Supongamos que w € G;, para algún ¿€ (2,3,...,2*—1). 
Por el lema 2, tenemos que 


w=(UC**9V)a (4) 


para algún a € FX. Sea b= C*7la, entonces, por ser C la 
matriz asociada a un polinomio primitivo de grado k, tenemos 
que 

as “es 00h 


Sustituyendo el valor de a, obtenido anteriormente, en la 
expresión (4) tenemos que 


w= (UC 9V)c%-= (vs vc? o 


con lo que w € f;, con j = 2+1-—i y así G, € F;. Ahora, 
como dim G, = dim F), necesariamente G; = F). 
Evidentemente j € (2,3,...,2* — 1). Además, si existe 
l € 12,3,.. .,2* — 1) tal que G; = F¡, entonces, necesaria- 
mente l = j. nm 
Finalmente, como consecuencia de los teoremas 1 y 2 
tenemos el siguiente resultado que nos permite construir el 


soporte de una función bent a partir de una base de IF7 y la 
matriz asociada a un polinomio primitivo de grado k en F2[X]. 


Corolario 2: Supongamos que 


A= [uz], uz,.. 


Up, U1,V2,... Un) 
es una base de F3 y consideremos las matrices 


U= [us us uz] y V= [v, va up]. 


Supongamos también que C' es una matriz asociada a un 
polinomio primitivo de grado k en Fa3[X], y definamos los 
subespacios vectoriales G;, para 1 0,1,2,...,2*, como 
en el teorema 2. Si IT C (0,1,2,...,2%) con |I| = 2*-=1 


(respectivamente, |I| = 914 1 ), entonces 
B= U G; (especie B=(0pU U c:) 
¡el ¡el 


es el soporte de una función bent de n variables. 


Ahora, con la notación del corolario 2, si |/| = 2%! y 
J=(0,1,2,...,2*1 I, y denotamos por f(x) y g(x) las 
funciones bent cuyos soportes son los conjuntos 


Br=l(]e; y B,=(0u US, 


¡el jes 
respectivamente, entonces g(u)=10 f(x). 


IV. PROCEDIMIENTO PRÁCTICO 


A continuación, describimos un procedimiento práctico para 
obtener los subespacios G; del teorema 2 a partir de una base 
A de FZ y la matriz C' asociada a un polinomio primitivo de 
grado k en F>[X]. Supongamos pues, como en el corolario 2, 
que agrupamos los vectores de 4 en dos matrices U y V de 
tamaño n X k. Así, de acuerdo con lo dicho en la sección IT, 
los vectores no nulos de Gp, G; para ¿=1,2,3,...,2*—1 y 
Go son, respectivamente, las columnas de las matrices 


VW=VH, V,=(UC?*!8V)H y Va =UH 


donde H es la matriz de control de paridad del [2* — 1, k]- 
código binario de Hamming. Por tanto, si consideramos, por 
ejemplo, el conjunto 7 = (0,1,2,3,...,2*=1 — 1), entonces, 
de acuerdo con los teoremas 1 y 2 y lo dicho anteriormente, te- 
nemos que las columnas de la matriz B siguiente, constituyen 
el soporte de una función bent de n variables. 


B=|W V Va V Var-1-1] 
=[| VE (USV)H (UCeV)H 
(UC? 9 V)H (vO? 2 6 v)H | 
El siguiente ejemplo nos ayudará a entender el proceso 
anterior. 


Ejemplo 1: Supongamos que n = 6 (y, por tanto, k = 3) y 
consideremos, por ejemplo, la base A = [1,2,4,8,16,32) 
y las matrices 


U=[1 2 4] y V=[8 16 32]. 
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Aquí 


RhO0O0DO0Oo0oOoOo 
or oooo 
a a a) 


y así sucesivamente; es decir, denotamos por 2 el vector 
columna correspondiente a la expansión binaria de 6 bits del 
entero ¿, para ¿=0,1,2,...,22 —1. 

Consideremos el polinomio primitivo p(X) =1+X+X3 € 
E>2[X] y su matriz asociada 


0 0 1 
C=|1 0 1 
0.1 0 
Finalmente, consideremos la matriz de control de paridad 
del [7, 3]-código binario de Hamming. 


De acuerdo con el proceso anteriormente descrito, tenemos 
que 


0.0.0.1 1 1 1 
VW=VH=|[8 16 32||0 1 1 0 0 1 1 
10.10.10 1 
=|[32 16 48 8 40 24 56), 
V=(USV)H=|[9 18 36] H 
=|[36 18 54 9 45 27 63], 
V,=(UCeV)H =|[10 20 35] H 
=[35 20 55 10 41 30 61], 
V¿=(UC?9W)H=|[12 19 38] H 
=|[38 19 53 12 42 31 57]. 


Por tanto, las columnas de la matriz 
B=[W Y Ya Vs] 


son los elementos del soporte de una función bent de 6 
variables. 

Si obtenemos las 22 +1 = 9 matrices V,, podemos construir 
E ) = 126 funciones bent pertenecientes a la clase PS” 
y 126 funciones bent pertenecientes a la clase PS*, siendo 
todas ellas distintas. 


Fijada una base A de F35 y un polinomio primitivo de 
grado k y coeficientes en F3, podemos considerar as ) 
subconjuntos Y de [0,1,2,...,2*) de 2*71 elementos y la 
misma cantidad de subconjuntos de 2*71 +4 1 elementos. Por 
tanto, de acuerdo con el teorema 2, podemos construir DA at ) 
soportes de funciones bent, que serán distintos dos a dos ya 
que si ¿,j € [0,1,2,...,2*) con ¡4 j, entonces V, H v;. 


V. PROBLEMAS ABIERTOS 


Ya hemos comentado al final de la sección anterior, que 
fijada una base de IF5 y un polinomio primitivo de grado k 
y coeficientes en F>, de acuerdo con el teorema 2, podemos 
construir 2 ) soportes de funciones bent, que son distintos 
dos a dos. Surge ahora, de modo natural, la pregunta siguien- 
te: ¿los Da (ei ) soportes de funciones bent construidos de 
acuerdo con el corolario 1 son distintos de los anteriores? El 
ejemplo siguiente pone de manifiesto que la respuesta no es 
necesariamente afirmativa. 


Ejemplo 2: Supongamos que n = 4 (y, por tanto, k = 2) 
y consideremos, por ejemplo, la base 4 = (1,2,4,8) y las 
matrices U = [1 2] y V= [4 8] . Consideremos el 
polinomio primitivo p(X) = 1+X+X? € F2[X], su matriz 
asociada C, y la matriz de control de paridad H del [3, 2]- 
código binario de Hamming. 

De acuerdo con lo dicho al inicio de la sección IV, tenemos 
que 


0 1 1 
1.0 1 


V=(USV)H=|[10 5 15], 
V.=(UCeWHA=|[11 6 13), 
V¿=(UC?9V)H =[9 7 14), 
V=UH=|[2 1 3]. 


Yo =VH = [4 s]| fs 4 12), 


Por tanto, al aplicar el corolario 2 a cada uno de los 
subconjuntos Y de (0, 1, 2,3, 4) de 2 elementos (análogamente 
para los de 3 elementos), obtenemos que cada uno de los 
conjuntos 

B; E 1, 2, 3, 4, 8, 12), 
B3 = (1,2,3,6,11,13), 

Bs = (4,5,8,10,12,15), 

B7 = (4,7,8,9,12,14), 

Bo = [5,7,9,10,14,15), 


Ba =(1,2,3,5,10,15), 

Ba = 11, 2, 3, A 9, 14), 

Bs = [4,6,8,11,12,13), 
Bs = [5,6,10,11,13,15), 
Bio =(6,7,9,11,13,14), 
es el soporte de una función bent de la clase PS” de 4 
variables. 

Ahora, si calculamos los complementos ortogonales de 
los subespacios vectoriales cuyos vectores no nulos son las 
columnas de las matrices V;, es decir, de los subespacios G; 
del teorema 2, obtenemos los subespacios ortogonales 

G =(0,1,2,3), G”?=(0,5,10,15), 
G5 =(0,7,9,14), GC? =(0,6,11,13), 
GÍ = (0, 4,8,12). 
Puesto que 
G5)=Ga G)=G,, GÍ)=G», 
GH =Gz y GL?=Go, 
es evidente que cada uno de los soportes construidos de 


acuerdo con el corolario 1 coincide con alguno de los soportes 
construidos de acuerdo con el teorema 1. 
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Consideremos ahora la base 4” = (9,11,12,4) y las 
matrices U' =[9 11] y V'=[12 4]. 
Procediendo como en el caso anterior, tenemos que 


VW=[4 12 8], V/=[15 5 10] 
V=[s 7 1], V¿=[13 14 3] 


vy=|[ 1 9 2] 


El 


El 


y, por tanto, cada uno de los conjuntos 


B! =(1,2,6,7,9,11), 

Bl =(1,4,6,7,8,12), 
B| =(2,3,9,11,13,14), 
B! =(2,5,9,10,11,15), 
Bh =(3,5,10,13,14,15), 


B)=(1,3,6,7,13,14), 
B,=(1,5,6,7,10,15), 

B¿ = [2,4,8,9,11,12), 
B¿ = [3, 4,8,12,13,14), 
Bioy = (4,5,8,10,12,15), 
es el soporte de una función bent de la clase PS” de 4 
variables. 

Ahora, si calculamos, como antes, los complementos or- 
togonales de los subespacios vectoriales cuyos vectores no 
nulos son las columnas de las matrices ve, es decir, de los 
subespacios G” del teorema 2, obtenemos los subespacios 
ortogonales 

(6) =40.1,235. (61)? =10,5, 10, 151, 
(6) =(0,6,8,14), (65) =(0,7,11,12), 
(64) = (0,4, 9,13), 
que proporcionan los siguientes soportes de funciones bent de 

la clase PS” de 4 variables: 


(B)W = (1,2, 3, 4,9,13), 
(BJ =(1,2,3,5,10,15), 
(BJ =(1,2,3,6,8,14), 
(BA <= 1,2,3:7, 11,19), 
(BJ = (4,5,9,10,13,15), 
(B¿) 5 = (4,6,8,9,13,14), 
(BN =(4,7,9,11,12,13), 
(BJ =(5,7,10,11,12,15), 
(BJ) =(5,6,8,10,14,15), 
(Bj) =(6,7,8,11,12,14). 


Notemos que en este caso, a diferencia de lo que ocurría en 
el caso anterior, ninguno de los conjuntos (BY coincide 
con ninguno de los conjuntos B;. 


Tal como se desprende del ejemplo anterior, y en todos los 
ejemplos que hemos comprobado, existen bases para las que 
cada uno de los soportes B coincide con alguno de los soportes 
B() y existen bases para las que ninguno de los soportes B 
coincide con ninguno de los soportes B(-), Este hecho sugiere 
los problemas siguientes: ¿Fijada una base cualquiera, son 
estas las dos únicas situaciones posibles? En caso afirmativo, 
¿bajo qué condiciones se da cada una de dichas situaciones? 


Además, si observamos de nuevo el ejemplo 2, vemos que 
B5 = Big, es decir, solamente uno de los soportes obtenidos 
con la base A coincide con uno de los soportes obtenidos con 
la base 4”. No ocurre lo mismo si consideramos las bases 
A y A” = (1,2,5,10), ya que en este caso, todos los 
soportes obtenidos con la base .4 coinciden con los soportes 
obtenidos con la base .4”. De nuevo, en todos los ejemplos 
que hemos comprobado se da alguna de estas dos situaciones, 
lo cual sugiere los problemas siguientes: ¿Dadas dos bases 
cualquieras, son estas las dos únicas situaciones posibles? En 
caso afirmativo, ¿bajo qué condiciones se da cada una de 
dichas situaciones? 

Otro problema que aparece en esta construcción es si influye 
o no el polinomio primitivo considerado. Es decir, ¿para 
una misma base y polinomios primitivos diferentes, podemos 
obtener idénticas funciones bent? ¿y si consideramos bases y 
polinomios diferentes? 

Estos y otros problemas que puedan surgir de esta construc- 
ción se abordarán en futuros trabajos. 
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Abstraci—En este trabajo se muestra que las secuencias 
obtenidas a partir de un generador de secuencia cifrante, el 
Generalized Self-Shrinking Generator (GSSG), son soluciones 
particulares de una ecuación en diferencias lineal homogénea 
con coeficientes constantes. Además de las secuencias producidas 
por el GSSG, la clase completa de soluciones de dicha ecuación 
incluye otras secuencias equilibradas muy adecuadas para crip- 
tografía, pues tienen el mismo periodo e incluso mayor com- 
plejidad lineal que las producidas por el GSSG. Los parámetros 
criptográficos de todas las secuencias anteriormente mencionadas 
pueden analizarse en términos de soluciones de ecuaciones en 
diferencias lineales. 


I. INTRODUCCIÓN 


Los generadores de secuencias pseudoaleatorias tiene nu- 
merosas aplicaciones en comunicaciones seguras, por ejemplo 
en redes inalámbricas, debido a ventajas prácticas tales como 
facilidad de implementación, alta velocidad y fiabilidad. A 
partir de una clave corta, un generador de secuencia binaria 
produce una serie larga de bits pseudoaleatorios denominada 
secuencia cifrante. La mayor parte de los generadores de 
secuencia cifrante están basados en Linear Feedback Shift 
Registers (LFSRs) [5] cuyas secuencias de salida, las PN- 
secuencias, se combinan de forma no lineal para producir una 
secuencia pseudoaleatoria de aplicación criptográfica. Gener- 
adores combinacionales, filtros no-lineales, generadores con- 
trolados por reloj o decimados de forma irregular son algunos 
de los ejemplos más conocidos que pueden encontrarse en la 
literatura [9], [13]. 

Coppersmith, Krawczyk y Mansour [1] propusieron el 
Shrinking Generator, luego Meier y Staffelbach [12] diseñaron 
el Self-Shrinking Generator, finalmente Hu y Xiao [8] 
definieron el Generalized Self-Shrinking Generator (GSSG) 
que genera una familia de secuencias pseudoaleatorias (que de- 
nominaremos secuencias generalizadas) muy adecuadas para 
uso criptográfico por tener largos periodos, buena correlación, 
excelente distribución de rachas, equilibrio entre ceros y 
unos, simplicidad de implementación etc. El GSSG puede 
considerarse como una especialización del generador shrinking 
a la vez que una generalización del generador self-shrinking. 
De hecho, la secuencia de salida del generador self-shrinking 
es un elemento de la familia de secuencias producidas por 
el GSSG. La idea fundamental de los generadores de este 
tipo es la decimación irregular de una PN-secuencia según 
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determinen los bits de otra. El resultado de esa decimación es 
la secuencia cifrante. Entre los criptoanálisis más destacados 
de generadores basados en decimación pueden reseñarse [3], 
[4], [7], 114], [15] y [16]. 

El trabajo aquí realizado se resume en dos ideas básicas: 


1) Se muestra que las secuencias generadas por un GSSG 
son soluciones particulares de un tipo de ecuación lineal 
en diferencias. 

Se muestra que algunas secuencias soluciones de la 
ecuación, aunque no estén incluidas en la familia pro- 
ducida por el GSSG, sí presentan buenas propiedades 
criptográficas. En general, las soluciones de las ecua- 
ciones lineales en diferencias proporcionan un método 
sencillo para la generación de secuencias pseudoaleato- 
rias. 


2) 


TI. EL GENERALIZED SELF-SHRINKING GENERATOR 
(GSSG) 


El GSSG es un generador de secuencia binaria que puede 
describirse tal y como sigue: 


1) Hace uso de dos secuencias: una PN-secuencia (a, | y 
una versión desplazada de la misma denotada por (vu, y. 

2) Relaciona ambas secuencias mediante una simple regla 
de decimación para generar la secuencia de salida. 


El resultado de los pasos anteriores es una familia de 
secuencias generalizadas que puede definirse de una manera 
más formal [8] como: 

Definición 1: Sea La, ) una PN-secuencia de periodo 2% —1 
generada a partir de un LFSR con polinomio característico 
primitivo y grado L. Sea G un vector binario de dimensión L 
definido como: 


G = (90, 91,92,---,91-1) € GF(2). (1) 
El n-ésimo elemento de la secuencia [v,,) se define como: 
Un, = Y0An O Y1An-1 O Y20n-2 0... DYL-10n-141) () 


donde los subíndices de la secuencia (La,,) se calculan mod 
22 — 1 y el símbolo Q representa la operación lógica OR- 
exclusiva. Para n > 0 la regla de decimación es muy sencilla: 


1) Si a, = 1, entonces v,, es bit de la secuencia de salida. 


2) Si an = 0, entonces v, se descarta y no hay bit de 
salida. 


De esta forma, se genera la secuencia de salida by b, ba... 
notada (by ó [b(G))+. Dicha secuencia es una secuencia 
generalizada o secuencia asociada a un valor de G. 

Nótese que la secuencia (0, no es más que una versión 
desplazada de la secuencia (a, ). Cuando G recorre el con- 
junto GF(2)* — (0,...,0), entonces [v,, ) corresponde a los 
21 —1 posibles desplazamientos de [a,,). Además, el conjunto 
de secuencias denotado por B(a) = [(b(G)),G € GF(2)*) 
es la familia de secuencias generalizadas basadas en la PN- 
secuencia (a, ). 

Ejemplo 1. Para la PN-secuencia fa, = (11110101100 
1000) con polinomio de realimentación at+a-+1, se obtienen 
16 secuencias generalizadas basadas en la PN-secuencia (a, ) 
(véase [8]): 


1. G= (0000), (b(G)) = 00000000 = 
2. G= (1000), (b(G)) = 11111111 = 
3. G = (0100), (b(G)) = 01110010 - 
4. G= (1100), (b(G)) = 10001101 = 
5. G= (0010), (b(G)) = 00111100 = 
6. G= (1010), (b(G)) = 11000011 = 
7. G= (0110), (b(G)) = 01001110 = 
8. G = (1110), (b(G)) = 10110001 - 
9. G= (0001), (b(G)) = 00011011 = 
10. G = (1001), (b(G)) = 11100100 = 
11. G= (0101), (b(G)) = 01101001 = 
12. G= (1101), (b(G)) = 10010110 = 
13. G= (0011), (b(G)) = 00100111 = 
14. G= (1011), (b(G)) = 11011000 = 
15. G= (0111), (b(G)) = 01010101 = 
16. G = (1111), (b(G)) = 10101010 = 


Es importante señalar que las secuencias generadas no son 
16 secuencias diferentes. De hecho, las secuencias 5 y 6 son 
versiones desplazadas de una misma secuencia y lo mismo 
sucede con las secuencias 11 y 12 y con la 15 y 16. Al 
mismo tiempo, las secuencias 3, 7, 10 y 13 corresponden 
a una única secuencia al igual que las secuencias 4, 8, 9 
y 14. Diferentes parámetros critográficos de estas secuencias 
tales como periodo o complejidad lineal se analizan en las 
siguientes secciones en términos de soluciones de ecuaciones 
en diferencias lineales. 


TIT. ECUACIONES EN DIFERENCIAS LINEALES CON 
COEFICIENTES CONSTANTES 


En este trabajo se considera el siguiente tipo de ecuación 
en diferencias con coeficientes binarios: 


(E 0 E. Ez =0, 


j=1 


n>0 (3) 


donde z, € GF(2) es el n-ésimo término de una secuencia 
binaria [z,, | que verifica la ecuación anterior. El símbolo E 
es el operador desplazamiento que actúa sobre los elementos 
Zn de la secuencia solución, es decir E?z,, = Zn+j- Los 
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coeficientes c; son valores binarios c; € GF(2) y r es un 
número entero. El polinomio característico de grado r de la 
ecuación (3) es: 
y 
Pla]=0 + Y ea, (4) 
j=1 

y especifica la relación de recurrencia lineal en (z,). Es 
decir, el n-ésimo término, z,, puede escribirse como una 
combinación lineal de los r términos precedentes: 


ds 
2n Y e Cj 2n-j=0, n>r. 6) 
j=1 


Si P(x) es un polinomio primitivo [10] y «q; es una de sus 
raíces, entonces 


2 (r—-1) 
E 


(6) 


son las r raíces diferentes de dicho polinomio (véase [11]). 
En este caso, se demuestra en [10] que la solución de (3) es 
una secuencia de la forma: 


€ GF(2) 


r—i 
=P 20 (7) 
j=0 
donde A es un elemento arbitrario de GF(2)”. Es decir, 
[zn) es una PN-secuencia de polinomio característico P(x) 
y periodo 2” — 1 cuyo inicio está determinado por el valor de 
A. 

Las ecuaciones en diferencias consideradas anteriormente 
pueden generalizarse a un tipo más complejo de ecuaciones 
cuyas raíces tengan una multiplicidad mayor que 1. De hecho, 
se consideran ecuaciones de la forma: 


(E 9 Y e EI 2 =0, 


j=1 


n>0 (8) 


siendo p un entero p > 1. El polinomio característico de 
este tipo de ecuación es: 


Pu(x) = Play? = (a | Y Es A (9) 
j=1 


Ahora las raíces de Par(x) son las mismas que las del 
E a Ñ 2 (r-1) 
polinomio P(x), es decir, (a,a?,a7,..., 2. ”), pero con 


multiplicidad p. Entonces las soluciones de (8) son [2]: 


p-1 ñ r-1 , A 
n= A? 2n ! 
(A, 


¡=0 j=0 


n>0 (10) 


donde A, € GF(2)” y los números combinatorios (”) se 
calculan mod 2. 
En resumen, el n-ésimo término (2, de una secuencia 
solución es la suma bit a bit del n-ésimo término de p 
r-1 E : 
secuencias (> 4% a”) (0 < ¡i < p) ponderadas por 


j=0 
coeficientes que son números combinatorios. 


De hecho, cuando n va tomando sucesivos valores cada 
número combinatorio (7) (n > ¿> 0) define una secuencia 


TABLE I 
NÚMEROS COMBINATORIOS, SECUENCIAS PRIMARIAS Y PERIODOS T; 


Núm. combinator. Secuencias primarias de 
a) Si=111,1,11,11,10) To =1 
E 51=(0,1,0,1,.0,1/0,d +) T, = 
el So =10,0,1,1,0,0,1,1=) T=4 
a) S3 =(0,0,0,1,0,0,0,1=)  T¿= 
dl Sa =(0,0,0,0,1,1,1,1 2) Ta = 
Ss =(0,0,0,0,0,1,0,1 ) Th = 
e Sé =(0,0,0,0,0,0,1,1 =) To =8 
la S7 =(0,0,0,0,0,0,0,1=)  T7= 


primaria con periodo constante 7. Se asume que e) = 0 para 
n < 1. En la Tabla l, aparecen representados los primeros 
números combinatorios con sus correspondientes secuencias 
primarias y periodos. Se aprecia que la generación de dichas 
secuencias sigue una regla sencilla. En efecto, para 2 = 0 la 
secuencia generada es la idénticamente 1, mientras que las 2”” 
secuencias primarias asociadas con (*;) para (2 < ¿ < 27+1) 
(siendo m un entero no negativo) tienen periodo T, = 27+1 
y sus dígitos son: 

1) Los primeros 2”” bits son ceros. 

2) Los siguientes 2”” bits son los primeros 2”” bits de la 

secuencia (, %.m). 

Lo vemos con un simple ejemplo. De acuerdo con la Tabla I 
y para m = 2, tenemos 2? secuencias primarias S, con (2? < 
¿ < 23). La secuencia Sy tiene 22 ceros y los 2? primeros 
dígitos de Sy. De la misma forma, la secuencia S5 tiene 2? 
ceros y los 2? primeros dígitos de S. Igualmente, la secuencia 
Sg tiene 2? ceros y los 2? primeros dígitos de S2 mientras que 
S7 tiene 2? ceros y los 2? primeros dígitos de 93. Por tanto, la 
generación y manipulación de tales secuencias en muy fácil. 


TV. PRINCIPAL RESULTADO 


Ahora se presenta el resultado fundamental que relaciona 
secuencias generalizadas con ecuaciones en diferencias. 

Teorema 1: La familia de secuencias generalizadas B(a) 
basada en la PN-secuencia (a, son soluciones particulares 
de la ecuación en diferencias lineal homogénea: 


(ES? z=0  p=2"*, (1D 


con polinomio característico (x + 1)?. 

Idea de la demostración: Como los periodos de las secuen- 
cias B(a) son T € (1,2,227*) [8], entonces el periodo T de 
cualquier secuencia es divisor de 22471, por tanto 27 +1 = 
(1 +1)7. Por otro lado, si f(x) es el polinomio característico 
de la menor relación de recurrencia verificada por la secuencia 
generalizada, entonces la condición f(x2)|x7 + 1 implica que 
F(x) es de la forma: 


Ha) = (+ 1340 


donde LC es la complejidad lineal de dicha secuencia. 
Por tanto las secuencias generalizadas verifican (11) y son 


(12) 


21 


soluciones particulares de dicha ecuación lineal en diferencias. 


Ahora podemos pues analizar al detalle las características de 
las secuencias que verifican la ecuación en diferencias previa. 
Según (10), las soluciones de la ecuación dada en (11) son 


ahora de la forma: 

n 
(7) 400 (D 40.0 (,7,) da 

donde A; € GF(2) son coeficientes binarios, a = 1 es 
la única raíz del polinomio (x + 1) de grado r 1 con 
multiplicidad p y (7) (0 < i < p) son números combinatorios 
mod 2. Nótese que la secuencia (z,) es simplemente una 
suma lógica bit a bit de secuencias primarias ponderadas 
por los correspondientes coeficientes A;. Así pues, diferentes 
elecciones de A; darán lugar a diferentes secuencias con 
distintas características. A partir de la ecuación (13) se pueden 
analizar aspectos particulares de las secuencias solución. To- 
dos ellos están relacionados con la elección de la p-tupla 
(Ao, A1, 4>,..., Ap-1) de coeficientes binarios. 


n 


il 


n 
=1 


a 


A. Periodos de las Secuencias Solución 


Según la sección 3, los periodos de las secuencias primarias 
son potencias de 2. Más aún, según (13) la secuencia (z,,) es 
la suma lógica bit a bit de secuencias de diferentes periodos. 
Luego, el periodo de [z,,) es el máximo periodo de las 
secuencias que aparecen en (13). De hecho, el period de [z,,) 
es el T, correspondiente a la secuencia primaria con el mayor 
índice ¡ tal que A; 40. 


B. Complejidad Lineal de las Secuencias Solución 


Según [10], la complejidad lineal de una secuencia coincide 
con el número de raíces de su polinomio característico que 
aparecen en su relación de recurrencia lineal. Según esto y 
analizando los coeficientes 4; en (13), se puede calcular el 
valor de la complejidad lineal. De hecho, tenemos una única 
raíz con multiplicidad p. Luego, si ¿es el mayor índice (0 < 
¿< p) para el que A; % 0, entonces la complejidad lineal es 
LC de la secuencia [z,] será: 


LC=:i+1 (14) 


puesto que será la multiplicidad de la raíz 1. 


C. Número de Diferentes Secuencias Solución 


Para contar el número de secuencias diferentes (z,,) que 
son soluciones de (11), volvemos igualmente a considerar los 
coeficientes A; en (13). Si ¿ (0 < ¿ < p) es el mayor subíndice 
para el que 4; % 0, entonces hay 2* posibles elecciones de la ¡- 
tupla (Ap, A1, Az, , A;-1) para la secuencia [z,,) en (13). Por 
otro lado, como el periodo de tal secuencia es T;, el número 
de secuencias diferentes NV; será: 


N;=Y/B  (0<i<p). (15) 


El número total V¿ota, de secuencias solución de la ecuación 
lineal en diferencias (11) será: 


p-1 
Niotal == > N,. 
1=0 


En resumen, la elección de los coeficientes A; permite 
generar secuencias binarias con periodo y complejidad lineal 
controlables. 


(16) 


V. UN EJEMPLO ILUSTRATIVO 


Volvemos al GSSG presentado en la sección 2. Para la 
PN-secuencia fa, ) = (111101011001000$ con polinomio 
primitivo de grado 4, la familia de secuencias generalizadas 
B(a) son soluciones de: 


(Eo1)Pb,=0,  p=2, (17) 


cuya forma general es: 


ja (5) 400 (*) 410...0 (7) Ar — n>0(18) 


Podemos considerar diferentes elecciones de la 8-tupla 
(Ao, Ar, A , Az): 

1) Para A; =0 Vi, la secuencia solución (b,,) = (0) es 
la secuencia idénticamente nula incluída ya en la familia 
de secuencias generalizadas. 

G = (0000), (b(G)F = 00000000 —- . 
Para Ay 40, A¿¡ =0 Vi > 0, la secuencia solución 
[b,) = (1111 —) es la secuencia idénticamente 1 que 
está incluída en la familia de secuencias generalizadas: 

G = (1000), (b(G)+ = 11111111 >. 
Una secuencia con Ty =1 y LCo = 1. 
Para 41 40, A; =0 V ¿> l, existe una única 
secuencia solución (b,,) con period T, =2 y LC, =2. 
El par (4p = 0, A1 = 1) genera (b,,) = [01 =) que 
corresponde a la secuencia generalizada: 

G = (0111), (b(G)+ = 01010101 - . 
El par (4p = 1, 4A1 = 1) genera (b,,) = (10 —] que 
corresponde a la secuencia generalizada: 

G = (1111), (b(G)+ = 10101010 > . 
Para Ag 4 0, A¿¡ =0 Vi > 2, existe una única y 
equilibrada secuencia solución (b,,) con periodo Ta = 4 
y LC) 3. Por ejemplo, la terna (Ap = 0,41 = 
0, A = 1) genera ([b,,) = (0011 =). Otras ternas 
con Az 1 dan lugar a versiones desplazadas de la 
misma secuencia pero ninguna de ellas es una secuencia 
generalizada. 
Para Az 40, A¿ =0 Vi > 3, existen 2 secuencias 
no equilibradas con periodo T3 = 4 y LC3 = 4. Al ser 
secuencias no equilibradas, ninguna de ellas pertenece a 
la familia de secuencias generalizadas. 
Para Ay 4 0, A; =0 V 1 > 4, hay 2 secuencias 
equilibradas diferentes con periodo T4 =8 y LC4 = 5. 
Por ejemplo, la S-tupla (Ap = 0,41 = 0,4» 


2 


— 


3 


= 


4 


= 


a) 


= 


6 


= 
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1, Az = 0, 44 = 1) genera (b,,) = (00111100 —) que 
corresponde a la secuencia generalizada: 

G = (0010), (b(G)| = 00111100 - . 
Mientras que la 5-tupla (Ay = 0,41 = 1,42 = 
1, Ag = 0, 44 = 1) genera (b,,) = (01101001 —) que 
corresponde a la secuencia generalizada: 

G = (0101), (b(G)) = 01101001 - . 

Para A5 4 0, A¿¡ = 0 Vi > 5, hay 4 secuencias 
diferentes no todas equilibradas con periodo T5 = 8 
y LC; = 6. Por ejemplo, la 6-tupla (Ap = 0,41 = 
1, Aa 1, Az 1, As 0, Az 1) genera 
[b,) = (01110010 ) que corresponde a la secuencia 
generalizada: 

G = (0100), (b(G)| = 01110010 - . 

Para Ag 4 0, A; =0 Vi > 6, hay 8 secuencias 
diferentes no todas equilibradas con periodo Tg = 8 y 
LC6 = 7. Ninguna de ellas corresponde a secuencias 
generalizadas. 

Sin embargo existen 4 secuencias solución equilibradas 
(b, = f01010110 “=), (b,) = (10101001 —), 
[b,) = [01011100 —) and [b, + = [10100011 =) con 
el mismo periodo, autocorrelación y mayor complejidad 
lineal que las secuencias generalizadas descritas en los 
pasos 6 y 7. 

Finalmente para A7 4 0, A; =0 VW 1 > 7, hay 16 
secuencias diferentes no equilibradas con periodo T7 = 
8 y LC7 = 8. Ninguna de ellas corresponde a secuencias 
generalizadas. 


7 


— 


8 


= 


9 


— 


E 
1 


5 


resumen, podemos concluir: 


— 


La selección de coeficientes A; permite controlar el 
periodo, la complejidad y el equilibrio entre ceros y unos 
de las secuencias solución. 

Todas las secuencias generalizadas, las 7 secuencias 
distintas del ejemplo anterior, aparecen como soluciones 
de la ecuación lineal en diferencias (17). 


2 


— 


VI. CONCLUSIONES 


En este trabajo se muestra que la familia de secuen- 
cias generalizadas, y por tanto las secuencia producida por 
el generador auto-shrinking, son soluciones particulares de 
ecuaciones en diferencias lineales. Al mismo tiempo, existen 
otras muchas secuencias solución no incluídas en la familia 
anterior que presentan las mismas o incluso mejores carac- 
terísticas criptográficas. Más aún, la elección de la p-tupla 
(Ao, 41, 42,..., Ap-1) de coeficientes binarios permite: 

1) Obtener todas las soluciones de la ecuación en difer- 
encías referenciada anteriormente (13), entre las que se 
encuentran secuencias con aplicación en cifrado en flujo. 

2) Generar secuencias cuyo periodo, complejidad lineal y 
equilibrio entre ceros y unos sea controlable. 


Hay que notar que aunque las secuencias generalizadas se 
obtienen por decimación irregular a partir de LFSRs, en la 
práctica son simples soluciones de ecuaciones lineales. Este 
hecho establece una sutil relación entre decimación irregular 


y linealidad que puede ser convenientemente explotada en el 
criptanálisis de tales generadores de secuencia. Una prolon- 
gación natural de este trabajo es la generalización de estos 
resultados a las llamadas secuencias interleaved [6], puesto 
que presentan una estructura muy similar a las secuencias 
obtenidas mediante decimación irregular. 
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Abstract—Como es bien conocido, los autómatas celulares la sección 4. Finalmente, en la sección 5 se presentan las 
elementales no cumplen de manera satisfactoria muchas de las conclusiones. 
propiedades criptográficas requeridas para su uso directo en 
el desarrollo de criptosistemas de clave secreta. Ello es debido 
fundamentalmente a la sencillez de las funciones booleanas en las 
que se basan sus reglas de transición local. En el presente trabajo A. Funciones booleanas 
se muestra cómo construir a partir de los autómatas celulares eS : : , Ñ 
elementales autómatas más complejos mediante la introducción Sea IF el espacio vectorial n-dimensional sobre el cuerpo 
del concepto de divergencia del autómata celular elemental. Se de Galois F2 = [0,1], y sea [e1,...,e,) su base canónica. 
estudian además las principales propiedades de propagación de Una función booleana (en n variables) es una aplicación de la 
la divergencia. forma f : FS —> Fa, siendo B.F,, el conjunto de las mismas; 
obsérvese que su cardinal es |BF,,| = 22. 

Se denomina peso de Hamming del vector u  = 


Han sido numerosos los trabajos publicados sobre los usos (u1,...,Un) E F3 y se denota por 1wt(u) al número de sus 
criptográficos de los autómatas celulares tanto en la crip- Coordenadas no nulas. Por otra parte, el peso de Hamming de 
tografía de clave secreta como en la criptografía de clave la función booleana f € BF, se define como 
pública (véase, por ejemplo, [1], [2], [7], [8]). Los autómatas e a 
celulares (AC para abreviar) están íntimamente relacionados wi (f) =|du € Fz tal que f(u) 4 031. 0) 
con las funciones booleanas ya que son dichas funciones las y más, la distancia de Hamming entre dos funciones 


que rigen su evolución cuando el conjunto de estados es F2.  hooleanas f.9 € BF, se define como d(f, 9) =wt(f 8 9) 
En consecuencia, el estudio de las aplicaciones criptográficas donde (10 a ON ) 


de los AC está muy ligado al estudio de las propiedades 
criptográficas de las funciones booleanas que definen sus 
funciones de transición local (equilibrio, características de 
propagación, no linealidad, resistencia, etc.). 


II. PRELIMINARES MATEMÁTICOS 


I. INTRODUCCIÓN 


La representación más común de las funciones boolenas es 
mediante su Forma Normal Algebraica (FNA), que no es más 
que su representación polinómica sobre Fa, es decir: 


Un tipo particularmente interesante de AC son los autómatas f(u,...,Un) =40 0 Dd Mio o ia 
celulares elementales. Se trata de AC cuyo conjunto de estados _1<k<n 
es Fa y cuya función de transición local viene definida por una 1<41 542». ix En 0) 


función booleana de 3 variables. Debido a la simplicidad de 
estas funciones, las aplicaciones criptográficas de este tipo de 
AC son limitadas. 

El objetivo principal de este trabajo es la búsqueda de un 


donde agp, a;,..., € F2. Se llama grado de la FNA al grado 
algebraico del polinomio. 
Una función vectorial booleana es una aplicación de la 


Ñ ; ] : forma: 
método simple que nos permita construir AC más complejos 
a partir de los autómatas celulares elementales y que posean F:Fi > FJ 
mejores propiedades de carácter criptográfico. En este sentido u > F(u=(5 (u),...,Fn (u) 6) 


se introduce la noción de divergencia de un autómata celular 

elemental y se estudian algunas de sus propiedades crip- donde F, : F% —>F2 son funciones booleanas en n variables. 

tográficas: el equilibrio y las características de propagación. La derivada parcial de una función booleana f € BF,, con 
El resto del trabajo se organiza como sigue: en la sección respecto a la ¿-ésima variable u; es otra función booleana 

2 se introduce la teoría básica sobre las funciones booleanas  D,f € BF, definida como sigue: 

y los autómatas celulares elementales; la divergencia de los 

autómatas celulares elementales se define en la sección 3, y Di¡f:F3 => Fa 

algunas de sus propiedades criptográficas son analizadas en uv > DiflwW=f(defí(uoe) (4) 
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El concepto de derivada parcial se puede extender al 
concepto de derivada direccional de la siguiente manera: la 
derivada direccional de f € BF, con respecto al vector 
bEFz es 


Dif: FB => Fa 
u > Dif(u)=f(u)o fue») 


(S) 


Obsérvese que la derivada parcial respecto a la variable u; 
no es más que la derivada direccional con respecto al vector 
e; € F3, esto es D¡f = De, f. Además se verifica el siguiente 
importante resultado (véase [5])): 

Teorema 1: Sea f € BF,, una función booleana y consid- 
eremos 1<%1 <%9<...< ip <n con k < n, entonces: 


(Do, 0--oDa,)f= BB Denomot O 


1<I<k 
e 
Ji EL, ,46) 


B. Autómatas Celulares 


Los AC (véase [11]) son máquinas de estados finitos consti- 
tuidas por mm unidades de memoria denominadas células que 
se disponen una a continuación de otra a modo de cadena. 
En cada instante de tiempo cada célula adopta un estado 
perteneciente al conjunto finito de estados F>3, de modo que 
el estado de la célula 2-ésima en el instante de tiempo t se 
denota por x! € Fa. Los estados de las diferentes células van 
cambiando en cada instante (discreto) de tiempo de manera 
sincronizada y de acuerdo a una determinada función de 
transición local f. Dicha función es una función booleana de 
k variables, con k < m, las cuales no son más que los estados 
de las células vecinas en el instante inmediatamente anterior 
de tiempo, es decir: 


FF > Fo 
) Po a n= 


(7) 


t t 
. Sesa) 


t t 
(osa ita itarr** 


para todo 1 < 2 < m. Consecuentemente, existen 92 posibles 
autómatas celulares. 

Obsérvese que los índices V = [ax1,...,azx) C Z definen 
la vecindad de cada célula del autómata celular (en este trabajo 
supondremos que las vecindades son homogéneas). En este 
sentido, si Y = [—q,...,0,...,q) se dice que el autómata 
celular posee vecindades simétricas de radio q. 

Como el número de células es finito, se deben establecer 
condiciones de contorno para asegurar que la evolución del 
AC se realice de manera correcta. Normalmente se consideran 
condiciones de contorno periódicas: 


1; =x) sii=pj (modm) para todo t. 


(8) 
El vector m-dimensional X* = (xí,...,wt,) € FI? se 
denomina configuración del AC en el instante de tiempo ?. 
La dinámica completa de un AC viene definida por la llamada 


función de transición global: 
9: FF? > FS 
X > 0(x)=x* 


(9) 
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Obsérvese que P viene definida por la siguiente función 
vectorial booleana: 


9 (u) = (0, (u),...,D,, (u)), (10) 


donde 
D, (u) = f (Uitar)-- 


es una función booleana en k variables. 

Un tipo particular y muy interesante de AC lo forman los 
Autómatas Celulares Elementales (ACE para abreviar). Estos 
autómatas poseen vecindades simétricas de radio q = 1, con 
lo que existen 22” = 256 de los mismos. Cada uno de ellos 
tiene asociado un número w que se puede calcular como sigue 
(véase [10]): 


(1D 


E 1<13<m, 


7 
0<w=)Y 0-2 < 255, 
1=0 


(12) 


donde la tabla de verdad de la función booleana f es la 
siguiente: 


RSAEARHROoooos” 
e 
pon 


RROrPoOoRror od 


um 


pun 
pun 


Rh RhO0Oo0orrRoo 
dedo dele dde «b Ed 


TII. DIVERGENCIA DE UN ACE 


En esta sección introduciremos el concepto de divergencia 
de un ACE y algunos resultados de interés para este trabajo: 

Definición 1: La divergencia de un autómata celular ele- 
mental cuyo espacio celular está formado por m células y 
cuya función de transición global viene dada por (9)-(11) es 
un autómata celular con p > m células, con vecindad 


e Si m es impar con m = 2r + 1, entonces: 


m-=—l1 m-=—1 
= -——,... co ——). 1 
y í 9 ) ,0, > 9) J (13) 
e Si m es par con m = 2r, entonces: 
m m 
V=i-=+1,....0,...,¿=+b. 14 
f 3 + E] e cd pal ( ) 


y cuya función de transición local es 


div(D):F5 —> Fa 


u > div(9) (u) = $) D,9, (u) (15) 
i=1 
Proposición 1: La divergencia de un ACE arbitrario cuya 
función de transición local viene dada por 


¿ tot ¿ " ¿ 
f E 2% Zi, fics) 40 Dd 0412¿_1 HD 422, Q 03 41 


t t t t 
Dar2t,_17, O 0132;_1%41 (16) 


tit t bt 
DazzT¡T¡y1 O 0123 ¡TT 415 


es 


div(0) (2í_,...,Ti,,) = 42 0 (412 O 093) S Dit 


j=r 
tot 
001238 rr Ci4r1 
t t 
D 01238 -r41Ti4r 
r-2 
tot 
913 O Miyjtigjya (17) 
j==r 


sim =2r +1es impar, y 


div (9) (27,1 -<-,Tiy7) = (012 O 093) DD yy 


j=—r+1 
t t 
O 0123 _r4+1VTi+r-1 
t t 
9 01238 _r49Ui pr 
r-2 
t t 18 
$ 4123 DirjTi4j+2- (18) 
j=-r+1 


si m = 2r es par. 

Obsérvese que la divergencia de un ACE viene definida 
por medio de tres parámetros: a2,412 $ 423 y 4123 cuando 
m es impar, y por sólo dos parámetros, a12 € 423 Y 4123, 
cuando m es par. Consecuentemente, existen 2% = 8 posibles 
divergencias para cada m impar y 2? = 4 divergencias 
distintas cuando m es par. Esas divergencias se muestran en 
la Tabla I y en la Tabla II, respectivamente. 

Este resultado permite clasificar los autómatas celulares 
elementales en diferentes clases de acuerdo a la divergencia. 
Esta clasificación se muestra en las Tablas III y IV. 


IV. PROPIEDADES DE PROPAGACIÓN DE LA DIVERGENCIA 


En esta sección estudiaremos algunas de las principales 
propiedades criptográficas que se deben satisfacer para poder 
usar la divergencia en el desarrollo de criptosistemas de clave 
secreta. Concretamente centraremos nuestra atención tanto en 
el estudio del equilibrio (balancedness en inglés) como en las 
propiedades de propagación. 


A. Equilibrio 


Como es bien sabido, las funciones booleanas de uso 
en criptografía deben ser equilibradas, es decir, las salidas 
producidas deben estar uniformemente distribuidas sobre Fa 
(véase, por ejemplo [3]). En este sentido si f es una función 
booleana en n variables entonces es equilibrada o balanceada 
cuando wt(f) = 2"71, Esta propiedad permite evitar la 
dependencia estadística que puede existir entre las entradas 
y las salidas de la función booleana y que es aprovechada por 
cierto tipo de ataques criptoanalíticos. 

Los ACE balanceados son los siguientes (véase [4]): 15, 23, 
27, 29, 30, 39, 43, 45, 46, 51, 53, 54, 57, 58, 60, 71, 75, 77, 
78, 83, 85, 86, 89, 90, 92, 99, 101, 102, 105, 106, 108, 113, 
114, 116, 120, 135, 139, 141, 142, 147, 149, 150, 153, 154, 
156, 163, 165, 166, 169, 170, 172, 177, 178, 180, 184, 195, 
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TABLE I 
EXPRESIONES DE LAS DIVERGENCIAS CUANDO m ES IMPAR 


Parámetros Divergencia 


Clase I 
az =0 
412 0 023 
q123 = 


=0 


Clase 
a = 
a12 $ 423 
4123 


t «tb Lo ab 
iorTigr1 DT yr ig 
r—2 a 

qt y 
DO ij 


j==r 


z 


Clase TI 
0 
a12 $ 423 
ar3=0 


a9 = 


y 
De 


j==r 


Clase IV 
as =0 
412 € a23 
aj23 =1 


+ 
t tont 
>) Tipj O Oia 
j==r 
r-2 


t t tot 
Oir 1 Tip O >) Dijo 42 
j=—r 


Clase V 
ag =1 
a12 0 423 
a123 =0 


Clase VI 
ag=1 
a12 9 a23 
aj23 =1 


tot LE z 
18 A ip O ri 
r-2 
tot 
DO Mtirj+2 


=—r 


Clase VII 
da = 
a12 0 a23 
aj23 =0 


Clase VII 
ay=1 

aj $a3=1 
a123 = 1 


r-2 
t t 
SD tit 


j==r 


TABLE HI 
EXPRESIONES DE LA DIVERGENCIA CUANDO Mm ES PAR 


Parámetros Divergencia 
Clase I 
aj $9 a73 =0 0 
a123 =0 
Ea T 6 T 
Clase II Viryi Tigra OO o Tip 
—-2 

a12 9 423 =0 E t t 
a123 = PON 14 Ui4j4+2 
Clase TI $ 

ads t 
aj2 $ a93 =1 4) Di 
aj3=0 i=-r+l 

Tr 
t t t 
Clase IV Ñ 8, Vii OT ri gr—1 
j==r 

a12 9473 =1 0 

3= t t to ont 
ar23=1 Or 2 Tigo O a ii +2 

j=>"r 


197, 198, 201, 202, 204, 209, 210, 212, 216, 225, 226, 228, 
232, y 240. 
En el caso que nos ocupa, el de las divergencias de los ACE, 
se obtienen los siguientes resultados: 
Si m es impar: 
+. Las clases I y V no son equilibradas ya que las diver- 
gencias son funciones booleanas constantes. Además las 
clases IV y VIII tampoco son equilibradas. 
+. Las clases III y VII son equilibradas ya que las diver- 
gencias son funciones booleanas afines no constantes. 
Además las clases Il y VI son también balanceadas. 


TABLE HI 
CLASIFICACIÓN DE LOS ACE DE ACUERDO A SU DIVERGENCIA CUANDO 
m ES IMPAR 


Clase ACE 


Clase 1 0,5,10,15,18,23,24,29,66,71,72,77,80,85,90,95,160, 
165,170,175,178,183,184,189,226,231,232,237,240, 


245,250,255 


Clase II 32,37,42,47,50,55,56,61,98,103,104,109,112,117, 
122,127,128,133,138,143,146,151,152,157,194,199, 


200,205,208,213,218,223 


Clase IM 34,39,40,45,48,53,58,63,96,101,106,111,114,119, 
120,125,130,135,136,141,144,149,154,159,192,197, 


202,207,210,215,216,221 


Clase IV 2,7,8,13,16,21,26,31,64,69,74,79,82,87,88,93,162, 
167,168,173,176,181,186,191,224,229,234,239,242, 


247,248,253 


Clase V 33,36,43,46,51,54,57,60,99,102,105,108,113,116, 
123,126,129,132,139,142,147,150,153,156,195,198, 


201,204,209,212,219,222 


Clase VI 1,4,11,14,19,22,25,28,67,70,73,76,81,84,91,94,161, 
164,171,174,179,182,185,188,227,230,233,236,241, 


244,251,254 


Clase VII | 3,6,9,12,17,20,27,30,65,68,75,78,83,86,89,92,163, 
166,169,172,177,180,187,190,225,228,235,238,243, 


246,249,252 


Clase VIII | 35,38,41,44,49,52,59,62,97,100,107,110,115,118, 
121,124,131,134,137,140,145,148,155,158,193,196, 


203,206,211,214,217,220 


TABLE IV 
CLASIFICACIÓN DE LOS ACE DE ACUERDO A SU DIVERGENCIA CUANDO 
mm ES PAR 


Clase ACE 


Clase 1 0,5,10,15,18,23,24,29,33,36,43,46,51,54,57,60, 
66,71,72,77,80,85,90,95,99,102,105,108,113,116, 
123,126,129,132,139,142,147,150,153,156,160, 
165,170,175,178,183,184,189,195,198,201,204, 


209,212,219,222,226,231,232,237,240,245,250,255 


Clase II 1,4,11,14,19,22,25,28,32,37,42,47,50,55,56,61, 
67,70,73,76,81,84,91,94,98,103,104,109,112,117, 
122,127,128,133,138,143,146,151,152,157,161, 
164,171,174,179,182,185,188,194,199,200,205, 


208,213,218,223,227,230,233,236,241,244,251,254 


Clase IM | 3,6,9,12,17,20,27,30,34,39,40,45,48,53,58,63, 
65,68,75,78,83,86,89,92,96,101,106,111,114,119, 
120,125,130,135,136,141,144,149,154,159,163, 
166,169,172,177,180,187,190,192,197,202,207, 


210,215,216,221,225,228,235,238,243,246,249,252 


Clase IV | 2,7,8,13,16,21,26,31,35,38,41,44,49,52,59,62, 
64,69,74,79,82,87,88,93,97,100,107,110,115,118, 
121,124,131,134,137,140,145,148,155,158,162, 
167,168,173,176,181,186,191,193,196,203,206, 


211,214,217,220,224,229,234,239,242,247,248,253 


Si m es par: 


La clase I no es equilibrada ya que la divergencia es la 
función booleana nula. 

La clase III es equilibrada puesto que la divergencia es 
una función booleana afín (no constante). 

Si además m no es múltiplo de 4 entonces la clase II 
es equilibrada (en otro caso -m par y múltiplo de 4-, la 
clase II es no equilibrada). 

Si m = 4,12,20... la clase IV es equilibrada (si m 4 
4,12,... no es equilibrada). 
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B. Propiedades de propagación 


En esta sección estudiaremos el Criterio Estricto de Avalan- 
cha (Strict Avalanche Criterion en inglés) y su generalización: 
el Criterio de Propagación (Propagation Criterion en inglés). 

1) Criterio Estricto de Avalancha: Se dice que una función 
booleana satisface el Criterio Estricto de Avalancha (utilizare- 
mos su acrónimo en inglés para abreviarlo: SAC) cuando la 
salida de la función cambia con una probabilidad de 0.5 siem- 
pre que se complemente un sólo bit de la entrada. Este criterio 
se puede caracterizar en términos de la derivada booleana 
como sigue (véase [9]): la función booleana f satisface el 
SAC si D;f es una función equilibrada para toda ¡j. En el 
caso de la divergencia, se verifica lo siguiente: 

Si m es par: 


+ Las derivadas parciales de las divergencias correspondi- 
entes a las clases 1 y II no son equilibradas puesto que 
se trata de las funciones booleanas constantes respectiva- 
mente: 


0, 
1. 


(19) 
(20) 


D., div (0) 
D., div (9) 


Por otra parte, las derivadas parciales de las divergencias 
de las clases II y IV son: 


D., div (0) 
D., div (0) 


Q1) 
(22) 


Uj—-2 YH Uz+2, 


190 4-2 0 Uj42, 


respectivamente (los subíndices se toman módulo m). 
Consecuentemente son equilibradas. 


Si m es impar: 
+ Las derivadas parciales de las divergencias de las clases 


I y V no son equilibradas ya que se trata de la función 
constante nula: 


D., div (d) =0. (23) 


e Las derivadas parciales de las divergencias de las clases 
III y VIT tampoco son balanceadas puesto que se trata 
también de funciones booleanas constantes: 


D.,div (9) =1, (24) 


+ Las divergencias cuyas derivadas parciales son equili- 
bradas son las correspondientes a las clases IL, VI y IV, 
VIII ya que un simple cálculo nos muestra que: 


De, div (D) 
D., div (D) 


(25) 
(26) 


Uj—-2 HD Uj+2, 


19 uj-2 9 Uj+2) 


respectivamente (recuérdese que los subíndices se toman 
módulo m). 


Por lo tanto, cuando m es par, sólo las clases II y IV son 


SAC, mientras que cuando m es impar, las clases que son 
SAC son la Il, la IV, la VI y la VIITL 


2) Criterio de Propagación: Para asegurar unas buenas 
propiedades de difusión, las funciones booleanas con apli- 
cación en la criptografía deben satisfacer el Criterio de Propa- 
gación (utilizaremos su acrónimo en inglés, PC -Propagation 
Criterion- para hacer referencia a él a partir de ahora). Este 
criterio fue introducido por B. Preneel ef al. (véase [6]) y 
está basado en las propiedades de las derivadas booleanas 
que muestran el comportamiento de las funciones estudiadas 
cuando algunas variables de la entrada son complementadas. 
Así, una función booleana de n variables, f, satisface el PC 
con respecto al subconjunto BC JE% si para todo b € Bla 
derivada direccional Df es equilibrada. Es más, la función 
booleana f satisface el PC de grado k (f es PC(k)) si dicha 
función satisface el PC respecto al siguiente conjunto: 


W (k) = [b € ES — (0) tal que wt (b) < k) 
=4fe1, D...0€e, 1<4 <...<i<n1<j<k). 
(27 


Obsérvese que el SAC no es más que el PC(1). 

En el caso que nos ocupa en este trabajo, se verifica lo 
siguiente: 

Las clases I y V cuando m es impar y la clase I cuando 
es par no satisfacen el PC ya que sus derivadas direccionales 
son la función booleana constante nula. 

Las clases !II y VII cuando m es impar y la clase IM cuando 
mes par tampoco satisfacen el PC ya que las divergencias cor- 
respondientes son funciones booleanas afines (no constantes) y 
sus derivadas direccionales son funciones booleanas constantes 
(y consiguientemente, no equilibradas). 

Las clases II y VI cuando m es impar, y la clase II cuando 
mes par satisfacen el PC, lo cual puede ser demostrado por 
recurrencia sobre k: 


. Si k= 1: Dado que las clases II y VI son SAC, entonces 
son PC(1). 
e Si k= 2: Teniendo en cuenta el Teorema 1, se verifica: 


De, oe NN (Blas o De) F 5) Des, Í 5) De, $ 
= De,, (Ui,-2 O Uiz42) 


D Ujo—2 Q 


D Ujio+2 


DU, -2 DU, +2 


19 4;,-4 8 41, -2 DU, OU 42, Si 11 = 02 — 2 


19 u;,-2 DU, DU 2 DU 44, Si 01 = 29 +2 


Ui,—2 5) Ur +2 6 Ui¿—2 5) U;js+2, en otro caso 


Aplicando la recurrencia sabemos que cada sumando de 
la forma D.,.0...dej, f es una función booleana afín no 


Deg, Fer BD F=0 para k > 
2; en consecuencia es, 0...Qei, $ es el sumatorio XOR 


de funciones booleanas afines no constantes y , por lo 
tanto, es equilibrado y satisface pues el PC(k). 


constante. Además Cs, 


Un argumento similar prueba que las clases IV y VIII con 
m impar, y la clase IV con m par satisfacen el PC. 


V. CONCLUSIONES 


Como es bien sabido, la evolución de los autómatas celu- 
lares elementales viene regida, en último extremo, por una 
función booleana de 3 variables. La simplicidad de estas 
funciones es uno de los principales motivos que hacen que 
no se utilicen directamente los ACE en el desarrollo de crip- 
tosistemas de clave secreta. No obstante, es posible construir 
autómatas celulares más complejos a partir de los ACE. En 
este sentido se ha introducido en este trabajo el concepto de 
divergencia de un ACE (con un espacio celular formado por 
m Células), cuya función de transición local viene definida 
por una función booleana de m variables. De manera más 
concreta, las funciones booleanas que definen las divergencias 
son las siguientes: 


F (Ut, «+; Um) = B, (30) 
F(ur,---¿Um) = B0Quitiso, (31) 
i=1 
f(u1,-.-,¿Um) = B0Qu, (32) 
i=1 
f (ur. Um) = B00D (ue uitiza), (33) 


i=1 
donde los subíndices se toman módulo m, y 8 =0,1 para m 
impar, y B =0 para m par. 

Se ha demostrado que las clases de divergencias derivadas 
de las funciones booleanas (30) son no equilibradas y no 
satisfacen los criterios de propagación. Las clases que se 
obtienen de las funciones de la forma (31) son equilibradas 
(con la excepción que se produce cuando m es múltiplo de 
4) y satisfacen también el criterio de propagación. Aunque 
las clases cuya función booleana es (32) son equilibradas, 
ellas no satisfacen los criterios de propagación. Finalmente, 
los autómatas celulares definidos por la función booleana (33) 


(28)son equilibrados para m = 4,12,20,... y satisfacen el criterio 


para todo 1 < 21 < 12 < n. Entonces Des, we S es una 
función booleana afín no constante y consecuentemente 
es equilibrada y es PC(2). 

+. Supongamos que la función es PC(k — 1), entonces: 


De, 0...De1, $ = (Dé Dio Deo) F (29) 
5) a De,,O...De;, f. 
1<I<k-1 
j1<...<ój 
Digi jEli1,.. $ 
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de propagación. 

En consecuencia, los ACE equilibrados cuyas divergencias 
son también equilibradas son los siguientes: 27, 30, 39, 45,53, 
58, 75, 78, 83, 86, 89, 92, 101, 106, 114, 120, 135, 141, 149, 
154, 163, 166, 169, 172, 177, 180, 197, 202, 210, 216, 225, 
228. Obsérvese que todos ellos pertenecen a las clases II y 
VI para m impar y a la clase III para m par. 

Además, si m no es múltiplo de 4 los ACE cuyas divergen- 
cias son equilibradas y satisfacen el criterio de propagación 
son los siguientes: 1, 4, 11, 14, 19, 22, 25, 28, 32, 37, 42, 47, 


50, 55, 56, 61, 67, 70, 73, 76, 81, 84, 91, 94, 98, 103, 104, 
109, 112, 117, 122, 127, 128, 133, 138, 143, 146, 151, 152, 
157, 161, 164, 171, 174, 179, 182, 185, 188, 194, 199, 200, 
205, 208, 213, 218, 223, 227, 230, 233, 236, 241, 244, 251 y 
254, 
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Abstract—Se describe una familia de generadores pseu- 
doaleatorios criptográficamente seguros basados en la combi- 
nación unidireccional de dos o más secuencias, generadas me- 
diante mapas caóticos lineales a trozos con coeficientes variables 
dinámicamente y rotación de bits variable dinámicamente. Se 
describen los conceptos y principios empleados en el diseño de 
los mismos. 


I. INTRODUCCIÓN 


Los generadores pseudoaleatorios son fundamentales en 
criptología ya que la seguridad de muchos sistemas crip- 
tográficos depende de la generación de secuencias pseu- 
doaleatorias bien sea en la criptografía de clave simétrica para 
cifrado en flujo [1], o en la criptografía de clave asimétrica 
para la generación de claves, vectores de inicialización o 
números primos. Sin embargo, generar una buena secuencia 
de números pseudoaleatorios no es una tarea fácil y sigue 
siendo un tema importante de investigación en ciencias de la 
computación y criptografía. 

El diseño de generadores pseudoaleatorios fiables sigue 
siendo un punto crítico en criptología. Algunos estándares 
de facto que se creían seguros han fracasado [2], [3], otros 
generadores que sí son seguros resultan poco útiles por su 
lentitud, como el BBS [4]. En 2000 comenzó el proyecto 
europeo NESSIE (New European Schemes for Signatures, 
Integrity and Encryption) que convocó un concurso, para el 
diseño de primitivas criptográficas. Lamentablemente, los seis 
cifradores en flujo presentados fallaron frente al criptoanálisis. 
En 2004 el proyecto europeo eSTREAM convocó el concurso 
para seleccionar un estándar de cifrador en flujo. Como resul- 
tado, en 2008 se seleccionaron siete finalistas del concurso (4 
en software y 3 en hardware) pero actualmente aún no se ha 
podido decidir cuál de ellos merece ser un estándar. 

El vínculo entre la criptografía y los sistemas caóticos está 
siendo objeto de un intenso estudio. Muchos investigadores 
están de acuerdo en que la interacción de estas áreas puede 
ser mutuamente beneficiosa. Muchas herramientas de análisis 
de los sistemas caóticos han servido igualmente como he- 
rramientas en el criptoanálisis de muchos sistemas y para el 
estudio y perfeccionamiento del diseño de otros [5], [6], [7]. 

En este trabajo se presenta una familia de generadores 
pseudoaleatorios que servirán como secuencia cifrante en un 
cifrador en flujo, partiendo de una aplicación caótica. Para 
evaluar la aleatoriedad de la secuencia pseudoaleatoria, su 
salida se compara con la salida de una secuencia realmente 
aleatoria, mediante pruebas estadísticas. 
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TI. FAMILIA DE GENERADORES PSEUDOALEATORIOS 
BASADOS EN LA COMBINACIÓN DE MAPAS CAÓTICOS 


La familia de generadores pseudoaleatorios propuesta se 
basa en la combinación de las secuencias generadas por varios 
generadores pseudoaleatorios básicos, mediante una función 
unidireccional. Cada uno de ellos está constituido por un mapa 
caótico, criptográficamente seguro por sí mismo, que tiene una 
entropía elevada. 


La combinación de varias secuencias mediante la función 
unidireccional tiene dos objetivos. El primero es conseguir 
aumentar el número de estados del sistema, con el consiguiente 
aumento del periodo de repetición, de la entropía y del número 
de claves. El segundo objetivo es el aumento de la seguridad. 
En efecto, al mezclar varias secuencias de forma que el tamaño 
de la palabra de salida sea menor que la suma de los tamaños 
de las palabras de entrada, resulta imposible hacer un análisis 
individualizado de las secuencias generadas por cada mapa 
caótico, dificultando en extremo un ataque criptoanalítico. 


Cada mapa tiene un número limitado de estados —y por 
tanto su período de repetición también es limitadlo— en 
función de la longitud de palabra del lenguaje con que se 
programe, que a su vez depende de la longitud de palabra del 
hardware que se utilice. El método de combinación elegido 
consiste en la suma módulo 2 bit a bit de los números 
generados por cada mapa caótico. El número de mapas debe 
elegirse en dependencia de la aplicación esperada y del número 
de bits que tengan las palabras del software con que se 
programe; dos configuraciones típicas equivalentes serían la 
combinación de dos mapas caóticos programados con 64 bits 
o de cuatro mapas caóticos programados con 32 bits. 


Se ha utilizado la mezcla de operaciones aritméticas y 
Operaciones orientadas a bit, porque ello sirve para evitar 
los ataques puramente algebraicos y los ataques puramente 
orientados a bits. El uso de la mezcla de una variedad de 
dominios en una forma no lineal y no algebraica, dificulta 
en extremo la posibilidad de modelizar el comportamiento 
matemático del esquema. 


Los procesadores modernos —cuando se opera con 
números de igual cantidad de bits que el tamaño de palabra de 
la máquina— pueden hacer de forma muy eficaz operaciones 
aritméticas módulo el tamaño de la palabra de la máquina, 
operaciones booleanas bit a bit y desplazamientos de bits. To- 
das estas Operaciones se combinan en el generador propuesto, 
logrando así una gran complejidad matemática junto con una 
elevada eficiencia computacional. 


A. Mapa caótico básico 


El mapa caótico utilizado F(x,,a,c,r) es de tipo unidi- 
mensional, consistente en la modificación de un mapa lineal 
a trozos mediante el incremento dinámico de coeficientes y 
la rotación dinámica de los bits de las muestras, que denomi- 
naremos abreviadamente como MLT-CDRD; siendo (x¿) la 
órbita caótica y a, C¿, r¿ los parámetros de control del sistema, 
definido por: 


24 = ((a1 2-1 +1) mod m) >> r;, (1) 
a = (a¿-1 + Aa) mod m, 

Cc; = [c4-1 + Ac) mod m, 

ri = (1-1 + Ar) mod n, 


donde t es el tiempo; nm es el número de bits de precisión 
utilizado; m = 2” es el número máximo de valores que puede 
tomar 2¿; 41, C¿, 74 SON coeficientes cuyos valores sufren res- 
pectivamente un incremento Aa, Ac, Ar a cada iteración del 
sistema; siendo Xp, Gp, Co, To los valores iniciales. El operador 
>> r, significa un desplazamiento circular a derechas de r 
bits de la expresión binaria de la palabra afectada, al que 
denominaremos abreviadamente rotación. 

La novedad de este mapa caótico radica en que se realizan 
dos operaciones de diferente índole concatenadas, la primera 
es una operación lineal x, = (a; 241 + c¿) mod m, propia 
de los generadores aleatorios algebraicos y la segunda es 
una rotación de bits >> r;, propia de los generadores con 
registro de desplazamiento. Tanto los coeficientes a, y c¿ como 
la magnitud de la rotación se varían dinámicamente con el 
tiempo. 

La función F(x) = ((a, 2-1 +C¿) mod m) >> ro, para 
Ty = constante, es biyectiva y, por tanto, invertible, con la 
consiguiente posibilidad de ser atacada criptoanalíticamente. 

Pero la misma función con r = q + Ar mod n —siendo 
Ar el incremento que sufre r a cada iteración del sistema— 
no es biyectiva, es decir que a cada elemento del conjunto 
de llegada le corresponden varios elementos del conjunto de 
partida, haciendo imposible su inversión y análisis por un 
atacante. 

Si se dibuja una gráfica bidimensional de los puntos de 
la órbita caótica [x¿) en función de (x¿_1), se obtiene el 
llamado mapa de retorno de la función, que en casos sencillos 
permite reconstruir el valor de los parámetros de una órbita 
caótica. 

A continuación se presentan cinco ejemplos que ilustran la 
estructura del mapa de retorno del MLECDRD para diferen- 
tes supuestos: sin rotación ni variación de coeficientes, con 
variación dinámica de coeficientes a; y c¿ Únicamente, con 
rotación constante rg únicamente, con rotación dinámica y, 
finalmente, con rotación dinámica y variación dinámica de 
coeficientes. 

1) Supuesto sin rotación ni variación dinámica: Si en el 
MLT-CDRD se toman los valores Aa = Ac = Ar = rg 
0, el mapa de retorno de la función x¿ = ((ay t¿-1 + Cz) 
mod m) >> r,, se reduce a un diente de sierra, con tantos 
tramos como el valor de ay y con una ordenada en el origen 
igual a Cy. En la Fig. 1 se representa este caso para ag = 5 y 
Co = 1, con una precisión n = 16 bits. El periodo máximo p 
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159) 


0 1 2 


3 2-1 4 5 


Fig. 1. Mapa de retorno de la función 1¿ = (5x¿_1 + 1) mod m, para 
m=21, 


se alcanza para ay mod 4 = cy mod 2 = 1, siendo su valor 
p = 2” = m, que es el máximo número posible de estados 
que puede adquirir la función [8]. 

La función F(x) = ((a; 2-1 + c¿) mod m) >> r;,, para 
estos valores de parámetro, es biyectiva y por tanto invertible. 

Es evidente que la seguridad proporcionada por un mapa de 
esta índole es mínima, pues se puede determinar fácilmente 
el valor de los parámetros que lo controlan por la simple 
inspección del mapa de retorno, confeccionado a partir de una 
colección de números generados por él. 

Este sencillo mapa coincide con el conocidísimo generador 
congruencial lineal, cuya falta de seguridad es sobradamente 
conocida [8], [9]. 

2) Supuesto con variación dinámica de los coeficientes: 
Un paso inicial hacia la seguridad del sistema consiste en 
incrementar a cada iteración los valores de los coeficientes 
Oj Y Ct. 

El mapa de retorno correspondiente se presenta en la Fig. 2, 
para ay =5, Aa=4, cp =1, Ac=4, rg =Ar=0 y 
n = 16 bits; el periodo máximo p se obtiene para a; mod 4 = 
c¿ mod 4 = 1, siendo su valor p = 2” = m. 

Obsérvese que el mapa de retorno no proporciona ninguna 
información acerca del valor de los parámetros, ni de su 
incremento. Pero, como el proceso es lineal, su carácter deter- 


Fig. 2. Mapa de retorno de la función x¿ = (as 241 ++) mod m; para 
a0=5, 4 =4a-1+4c0=1,c4=c-1+4m=2*, 


Fig. 3. Mapa de retorno la función x¿ = ((5x¿-1 + 1) mod m) > r 
parar =3 y m= 2%, 


minista y la función 1, = ((a; 141 +c,) mod m) >> r;, para 
estos valores de parámetro, es biyectiva y por tanto invertible, 
siempre será posible calcular el valor de los parámetros a 
partir del estudio de los sucesivos valores de x¿, resolviendo 
un sencillo sistema de ecuaciones lineales. Por ello la mejora 
de la seguridad es limitada. 

3) Supuesto con rotación constante: Una alternativa dife- 
rente consiste en aplicar una rotación al mapa lineal a trozos. 
La rotación es una operación que se hace de forma eficiente 
tanto en software como en hardware, pero que es no lineal 
y resulta compleja de modelizar algebraicamente, así se tiene 
que su expresión algebraica es: 


a>r=|l2/2] + (1277) mod 2”. 


En la Fig. 3 se ilustra el mapa de retorno de la función 
para los valores de parámetro Aa = Ac = Ar = 0, ay = 5, 
Co =1ym= 16, valores que sólo difieren de los del supuesto 
primero en que ahora hay una rotación fija rg = 3. 

Se puede comprobar que cada uno de los tramos ay del 
diente de sierra de la Fig. 1 se ha desdoblado en 2” tramos 
paralelos con una pendiente 2” veces menor; resultando aún 
posible deducir el valor de los parámetros mediante la inspec- 
ción del mapa de retorno. 

La función F(x) = ((a, 241 + C¿) mod m) >> r;, sigue 
siendo biyectiva; pero la novedad importante es que el periodo 
de repetición de la secuencia generada es imprevisible y 
depende de los valores de los parámetros y de la rotación. 
Experimentalmente se han encontrado periodos comprendidos 
entre el 1% y el 80% del periodo sin rotación p = 2”. El efecto 
es que se ha producido un avance hacia la impredecibilidad 
de la secuencia, al precio de una reducción del periodo. 

4) Supuesto con rotación dinámica: Otra mejora de la 
entropía consiste en modificar el caso anterior variando 
cíclicamente el valor de la rotación. 

En la Fig. 4 se ilustra un caso igual al anterior con la sola 
diferencia de que ahora se hace rg = 0 y Ar = 1. Se puede 
observar que el mapa de retorno es extremadamente complejo, 
aunque aún se puede intentar alguna estimación del valor de 
los parámetros. 

El resultado importante es que no sólo ha aumentado la 
confusión del mapa de retorno, sino también el periodo de 
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Fig. 4. 
para rg =0, T¿ = T¿-1 + 


Mapa de retorno la función x¿ = ((5x¿_1 + 1) mod m) >> r+ 
lym=21, 


repetición de la secuencia, se observan ocurrencias de periodos 
comprendidos entre el 20% y el 1600% del periodo sin 
rotación p = 2”. Los periodos más cortos se originan para 
los valores de Ar que tienen más factores primos comunes 
con n. 

La función F(x) = ((a; 2-1 + Cc¿) mod m) >> r,, para 
Ar 4% 0 no es inyectiva ni sobreyectiva, ya que a cada 
elemento del conjunto de llegada le puede corresponder más 
de un elemento del conjunto de partida. 

5) Supuesto con rotación dinámica y variación dinámica 
de coeficientes: Finalmente, en la versión completa del MLT- 
CDRD se consigue la entropía óptima combinando todos los 
mecanismos anteriormente descritos. 

La Fig. 5 ilustra el mapa de retorno para los valores de 
parámetro: ay =5, Co =1, 10 =0, Aa=4x3, Ac=4x l, 
Ar =3 y n= 16. Nótese que el mapa de retorno contiene 
muchos más puntos que cualquiera de los sistemas anteriores, 
debido a que el período es mucho más largo y a una mayor 
entropía. 

Los valores de los coeficientes han de cumplir las siguien- 
tes condiciones para maximizar el periodo de repetición: ay 
mod 4 = cy mod 2 = 1, Aa mod 4 = Ac mod 2 = 0, tal 
como se demuestra en [8]83.2.1.2, Teo. A, cuando se estudia 
el generador lineal congruencial. Nótese que estas condiciones 
han de cumplirse aunque el valor de los parámetros varíe 
dinámicamente. 

Los valores ro y Ar han de elegirse de tal forma que se 
maxiímice el periodo de repetición de la sucesión de los valores 
de la rotación, para conseguir el máximo de entropía; lo que 
conduce a que Ar sea relativamente primo con n; rg puede 
ser cualquier valor 0 < ry < n. 

En la Fig. 5 se ha representado un número de puntos 
N = 4m = 21% de la órbita del generador. Naturalmente, 
si se siguiesen representando más puntos se rellenaría toda 
la superficie del mapa de retorno, es decir que el mapa es 
completamente uniforme. Este hecho no ocurría en ninguno de 
los supuestos anteriores ya que cuando los puntos se agrupaban 
en rectas era evidente que la uniformidad era inexistente. En 
el caso (aparentemente mejor) de la Fig. 2, la uniformidad 
es limitada ya que si se dibujase más de un periodo los 
puntos de los periodos sucesivos caerían sobre los dibujados 


Fig. 5. Mapa de retorno la función x¿ = (a¿1¿—1 +C¿ mod m) >> r: para 
ay =5, 4 =01-1+12,c0=1, 4 =C-1+470=5, 514=4-1+3 
y m=216, 


anteriormente (el periodo de la órbita era p = m = 219), 

En la versión completa con n = 16 bits hemos observado 
ocurrencias de periodos comprendidos entre 132 y 66000 
veces la longitud del periodo sin rotación p = 2”, para 
diferentes valores de los parámetros, manteniéndose estas 
proporciones cuando se codifica con mayor cantidad de bits. 
Es decir, que se consiguen períodos notablemente más largos 
que los esperables con el sencillo generador del supuesto 
primero. 

La función F(x) = ((as 2-1 + c¿) mod m) >> ry, para 
Ar 4 0 no es inyectiva ni sobreyectiva ya que a cada elemento 
del conjunto de llegada le puede corresponder más de un 
elemento del conjunto de partida. El número M de elementos 
diferentes entre sí del conjunto de llegada obedece a la fórmula 
del problema del cumpleaños: 


N-1 
=-1 
Mom(122) 


m 


(2) 


siendo N el número de muestras generadas. Para una precisión 
n = 16 bits, el número máximo de muestras diferentes es 
m = 216, Si se prueban exactamente los m valores posibles 
del conjunto de partida, sólo aparece un 63,22% de valores 
diferentes del conjunto de llegada, es decir el 36,78% de los 
elementos de llegada están repetidos. Por tanto, no es posible 
invertir la función, ya que aproximadamente un tercio de los 
elementos del conjunto de llegada tiene más de una preimagen. 

Las muestras generadas por el mapa 1, = ((a; 241 + C;) 
mod m) >> r;, también están de acuerdo con la Ec. 2; es 
decir, para un número de muestras generadas igual a N = 
216, las muestras diferentes son M = 0,63 N, para N = 2!” 
las muestras diferentes son M = 0,86 N, para N = 21 las 
muestras diferentes son M = 0,98 N y para para N = 21% 
las muestras diferentes son M = N. 

Este comportamiento estadístico es exactamente igual al 
que se podría esperar de una fuente de números totalmente 
aleatoria, lo que confirma la perfecta pseudoaleatoriedad de la 
secuencia generada. 

Las secuencias de números generados por el MLT-CDRD, 
(en su versión con n = 64 bits) pasan con éxito todas las 
pruebas de la batería de tests de aleatoriedad del American 
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National Institute of Standards and Technology, recogidos en 
la NIST SP 800-22 [10], así como las más exigentes Diehard 
de Marsaglia de 1995 y también los nuevos, y aún más 
exigentes, Tuftests de Marsaglia y Tsang de 2002 [11]. 

La versión completa del MLT-CDRD programada en C99 
—estándar ISO/IEC 9899:TC3— con números enteros de 
precisión extendida de 64 bits significativos, ha conseguido 
un rendimiento de 2,5 bits por ciclo de reloj en un ordenador 
de tipo PC con procesador Intel. 

Una interesante característica de este mapa caótico, es 
que puede generar simultáneamente múltiples secuencias in- 
dependientes, todas de idéntico periodo, con un esfuerzo 
computacional adicional mínimo, simplemente haciendo si- 
multáneamente varias operaciones de rotación con parámetros 
To y Ar de valores diferentes. 


B. Coeficiente de Lyapunov 


Para que exista caos en un sistema determinístico debe 
haber dependencia sensible a las condiciones iniciales. Ello 
significa que las órbitas de dos puntos iniciales próximos 
divergerán exponencialmente. Siguiendo a Moon [12], si dy 
es una medida de la distancia inicial entre dos órbitas, y dx 
es una medida de la distancia entre las mismas órbitas al cabo 
de k iteraciones, se define, 

dy 
do do ! 
siendo Á el exponente de Lyapunov correspondiente a k 
iteraciones. La base sobre la que se aplica el exponente puede 
elegirse según convenga. Se ha tomado la base 10 porque se 
trabaja con números enteros. 

El exponente de Lyapunov sirve para medir el caos de un 
sistema. Si A = 0, la distancia se mantiene y no se puede 
afirmar que exista caos. Si Á < 0, la distancia disminuye, el 
sistema converge y no es en absoluto caótico. Si A > 0, la 
distancia aumenta, hay dependencia sensible a las condiciones 
iniciales, se produce una divergencia exponencial de la órbita 
y ésta es tanto más caótica cuanto mayor sea el valor de A. 

En la mayoría de los problemas físicos la órbita está acotada 
y, por tanto, dz no tiende a infinito al aumentar el número 
de iteraciones. La divergencia de las órbitas debe entenderse 
sólo como localmente exponencial; por ello, se han calculado 
sucesivamente los exponentes de Lyapunov cada n iteraciones 
(que sería el periodo de las rotaciones) y se ha tomado la 
media al cabo de un número K' de iteraciones suficientemente 
grande 


o 1 
E qe, ds z 19810 


donde do, y d,,, son las distancias inicial y final en la iteración 
k. 

En la Fig. 6 se ilustra la variación del exponente de 
Lyapunov en función los valores posibles de ap, para el mismo 
ejemplo del supuesto quinto (para su cálculo se ha tomado 
K = n). La media de los valores de los coeficientes de 
Lyapunov alcanza el valor 0,2605, para todos los valores 
de ay que cumplen, ag mod 4 = 1. Nótese que todos los 
exponentes están agrupados en una estrecha franja de valores, 


4 
x 10 


Fig. 6. Exponentes de Lyapunov en función de ay de la versión completa 
del MLT-CDRD. 


garantizando la rápida divergencia de las órbitas para todos 
los ap. 


C. Combinación de los mapas 


La versión completa del mapa MLT-CDRD puede ser por sí 
misma un excelente generador de números pseudoaleatorios; 
pero como en cualquier diseño de esta índole quedan algunos 
cabos sueltos que requieren ser totalmente asegurados. 

El primer problema consiste en que si el MLIE-CDRD se 
programase con palabras de pocos bits, por ejemplo con 
n = 32, el periodo de repetición podría resultar relativamente 
pequeño para ciertas aplicaciones que requiriesen períodos 
extremadamente largos. 

El segundo problema radica en que nadie puede garantizar 
que no aparezcan puntos fijos o ciclos cortos del generador 
para algún conjunto de parámetros y valores iniciales. El 
carácter totalmente impredecible del generador, debido a su 
estructura no lineal —que mezcla operaciones algebraicas y 
operaciones bit a bit— solamente permite hacer estimaciones 
estadísticas de su comportamiento. La experiencia demuestra 
que la posibilidad de puntos fijos o ciclos cortos es muy 
remota, pues se han realizado pruebas exhaustivas del com- 
portamiento para valores pequeños de n (concretamente para 
6 bits) y numerosos ensayos para n = 32 y n = 64 bits, 
todos ellos totalmente satisfactorios en cuanto al período de 
repetición y a la aleatoriedad. 

El tercer problema es que en el MLT-CDRD los números 
generados que aparecen a la salida son los mismos que se 
emplean como entrada para generar la muestra futura, permi- 
tiendo a un atacante comparar la salida y entrada del mapa, 
lo que posibilitaría intentar algún tipo de análisis dirigido a 
estimar matemáticamente el valor de los parámetros o parte 
de ellos. 

Para hacer frente a todos estos inconvenientes se propone 
una familia de generadores basados en la combinación de dos 
o más MLECDRD mediante una función unidireccional. 

A continuación se describe el ejemplo más sencillo posible, 
en el que se combinan dos mapas caóticos programados con 
palabras de 64 bits, como se ilustra en la Fig. 7, que mezcla 
dos secuencias [1x¿) e [y¿) mediante la suma XOR bit a bit, de 
forma que se resuelven satisfactoriamente todos los problemas 
anteriores. 

El primer mapa está definido por las Ecs. 1 y el segundo 


35 


(a,x,¡ + c,) mod m 


>>> Y, >> 


bj bos 


(b,y,.1 + d, ) mod m 


Fig. 7. Generador pseudoaleatorio completo, combinando dos MLT-CDRD. 
es: 
Yi = ((b, Yt—1 + d;) mod m) >> St, (3) 
di = (di-1 ar Ab) mod m, 
di = (di-1 Al Ad) mod m, 
si =(s;-1 + As) mod n, 


siendo (070) A do, Co A do, Aa A AD, Ac Á Ad; TO Á SO» 
Ar 4% As, para asegurar que las secuencias (1,) y [y¿) sean 
absolutamente diferentes. 

Igualmente se podrían combinar mediante la suma XOR bit 
a bit tantos MLT-CDRD como fuesen necesarios para alcanzar 
el periodo de repetición deseado. 

El primer problema queda resuelto por la combinación de 
varios mapas MLT-CDRD, por lo que el número de estados del 
generador se amplia tremendamente. Si se estaba trabajando 
con palabras de 64 bits, el número de estados pasa de 2% = 
1210432843 109, 

El segundo problema se resuelve con la perturbación de la 
entrada de cada mapa x¿ e y¿ mediante la suma XOR bit a 
bit de las salidas de cada uno, x;_1 e y;-—1, con el estado 
de dos contadores (I y D) de igual numero de bits cada uno 
que el MLECDRD. Ambos contadores están en cascada; es 
decir, cada vez que el contador I da una vuelta completa se 
incrementa en una cuenta el contador D. De esta forma se 
garantiza que el periodo sea, como mínimo, el periodo de los 
dos contadores en cascada. Si se trabaja con palabras de 64 
bits, el número de estados garantizado sería 2128 = 3, 4x 10%, 

El tercer problema queda resuelto por la mezcla de varias 
secuencias en una sola, de forma que el tamaño de la palabra 
de la secuencia combinada (tw,) sea igual al tamaño de las 
palabras de cada una de las secuencias [x¿) e (y) a combinar, 
resultando imposible hacer un análisis individualizado de las 
secuencias generadas por cada mapa caótico. Para potenciar 
al máximo esta operación de ocultación, no se suman XOR 
bit a bit directamente las secuencias [1,) e [y], sino unas 
variantes de estas [1/) e [y¿), que difieren de las anteriores 
en que se utilizan rotaciones diferentes r, 4 r¿ y s, % sy, para 
generarlas. 

La clave del generador está constituida por los coeficientes 


de los mapas caóticos y las semillas xy e yo y los valores 
iniciales de los contadores pueden también formar parte de 
la clave o bien ser conocidos. Debido a las limitaciones 
impuestas en el supuesto quinto, el número de bits con que se 
codifican los coeficientes es: n — 2 bits para ag, by, Aa, Ab; 
n—1 bits para Co, do, Ac, Ad; (log, n)—1 bits para Ar y As; 
y log, n bits para ro y So. Si se trabaja con palabras de 64 
bits, el número total de bits de clave sería 4 x 62 +4 x 63 + 
2x5+2x6 = 522. Ahora bien, dado que los coeficientes 
utilizados por un MLECDRD no deberían repetirse en el otro 
MLT-CDROD (para generar secuencias radicálmente diferentes 
en cada uno), se puede considerar que el número total efectivo 
de bits de los coeficientes ha de reducirse a unos 521. Si se 
suman los bits de las semillas (haciendo conocido los valores 
iniciales de los contadores) el número final de bits de la clave 
sería 649 y el número final de claves 2%. 

1) Seguridad: La forma evidente de atacar el sistema, 
cuando se conoce la secuencia de números de salida y el estado 
de los contadores, es la prueba exhaustiva de claves; pero dada 
su cantidad la operación es prohibitiva. Existe la posibilidad 
de un ataque por encuentro a medio camino; pero ello exigiría 
generar y almacenar un promedio de 2%% conjuntos de al 
menos 10 muestras de salida, lo que también es inviable. 

2) Aleatoriedad: Las secuencias de números generados por 
el generador combinado también pasan con éxito todas las 
pruebas de la batería de tests de aleatoriedad SP 800-22 [10], 
las Diehard de Marsaglia así como los Tuftests de Marsaglia 
y Tsang [11]. 

3) Velocidad: El precio pagado por la combinación de dos 
MLT-CDRD —igualmente programada en C99 con enteros 
con precisión extendida de 64 bits significativos—, ha sido 
que el rendimiento se ha reducido a 1 bit por ciclo de reloj 
en un ordenador de tipo PC con procesador Intel y SO 
Windows32. Hay que señalar que esta velocidad está al nivel 
de la conseguida por los finalistas del concurso eSTREAM. 


TII. APLICACIONES 


La familia de generadores descrita es apropiada para usarse 
en aplicaciones criptográficas especialmente exigentes, como 
la generación de claves y el cifrado en flujo. 

Dentro del proyecto CENIT SEGURE encargado por 
Telefónica I+D al CSIC, se han realizado varios desarrollos 
basados en este generador, entre ellos un cifrador en flujo 
síncrono, un cifrador en flujo autosincronizante, un generador 
de claves y un generador de MAC's de archivos. Estos 
desarrollos se han aplicado en telefonía móvil al cifrado 
de SMS para móviles con SO Windows Mobile 6.0/6.5 y 
Symbian y para cifrado de correo electrónico y archivos 
en Windows Mobile 6.0/6.5 en móviles 3G; funcionando 
satisfactoriamente en tiempo real. 

Se ha solicitado la concesión de una patente internacional 
a nombre de Telefónica S.A. 
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IV. CONCLUSIÓN 


Se ha descrito el diseño de una familia de generadores 
pseudoaleatorios criptográficamente seguros basados en la 
combinación unidireccional de dos o más secuencias, gene- 
radas mediante mapas caóticos lineales a trozos con coefi- 
cientes variables dinámicamente y rotación de bits variable 
dinámicamente. El generador es impredecible, de periodo de 
repetición mínimo garantizado, y satisface los test de aleato- 
riedad actualmente más exigentes. La velocidad de generación 
alcanzada es de un bit por ciclo de reloj en un PC con 
procesador Intel y SO Windows32. 

La característica destacada es la combinación de opera- 
ciones algebraicas con operaciones booleanas y desplazamien- 
tos circulares, cuya asociación maximiza la seguridad y la 
entropía del sistema. 
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Abstract—The security of chaos-based cryptosystems is closely 
related to the possibility of recovering control parameters and/or 
initial conditions from partial information on the associated 
chaotic orbits. In this paper we analyze this possibility for the case 
of unimodal maps. We show a meaningful set of contexts where 
the dynamics of unimodal maps can be reconstructed, which 
means a relevant reduction of the scope where this kind of chaotic 
maps can be applied to build up new encryption procedures. 


TI. INTRODUCTION 


Chaos-based cryptography uses chaotic systems to guide the 
encryption procedure inside an encryption architecture. The 
examination of the adequacy of a specific chaotic map for 
an encryption architecture is a very complex problem, and 
we have the feeling that a general solution to this problem 
cannot be found. As a matter of fact, even for non-chaos-based 
encryption systems, it is not possible to establish a general 
security evaluation procedure. Therefore, the evaluation of the 
security of a cryptosystem is generally an ad hoc procedure, 
and the starting point should be the set of strategies used by 
cryptanalysts. The first step in either the design or the security 
analysis of a cryptosystem is to detect the components which 
could be examined or studied using previous cryptanalysis 
techniques. In other words, it is necessary to identify the 
critical components of a cryptosystem before starting its design 
or cryptanalysis. 

In the case of chaos-based cryptosystems, the identification 
of these critical components must focus in a first approxima- 
tion on three points: the selection of the encryption architec- 
ture, the selection of the chaotic system(s) and the procedure 
that determines the association between the chaotic system(s) 
and the encryption architecture. With respect to the selection 
of the encryption architecture, if we assume symmetric cryp- 
tography, it is necessary to discern between stream ciphers 
and block ciphers. In [1, Chapters 3 and 4] a detailed analysis 
Of various attacks on conventional stream and block ciphers 
can be found. For chaos-based cryptography, it is natural that 
those attacks should anyway be considered, by considering 
that now the cryptosystems under study are driven by chaos. 
Concerning the selection of the chaotic system(s), we have 
to examine thoroughly two critical aspects: (1) the complexity 
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of the chaotic systems; (11) the possibility of reconstructing 
the dynamics of the chaotic system(s) from the information 
leaked, in different cryptanalysis contexts associated to a given 
encryption architecture. 

The complexity of the underlying chaotic systems depends 
on both their dimensionality and their physical implementa- 
tion. According to Poincaré-Bendixson Theorem [2, p. 101], 
chaotic dynamical systems in continuous time have a phase 
space of dimension greater than 2. Conversely, dynamical 
systems in discrete time can be chaotic even when the phase 
space is of dimension 1, if the rule of evolution is a non- 
invertible function. On the other hand, chaotic systems can 
be implemented in analog (i.e., upon some circuitry) or in 
digital form. The first option is generally associated to the 
use of chaos synchronization techniques [3], [4], which is 
not the case in the second option. The digital alternative 
demands an analytical description of the chaotic system. If 
the chaotic system is described in continuous time, then its 
analytical definition is a set of differential equations, and the 
determination of its temporal evolution requires the use of 
numerical methods. The use of such methods informs about 
an extra burden (in terms of computation) when calculating 
the orbits of the chaotic systems. Moreover, it incorporates 
an extra problem, since numerical methods are defined in 
dependence of configuration parameters. These parameters 
must be selected carefully, otherwise the dynamics of the 
resulting orbits can be modified resulting in a non-chaotic 
behavior (this is the case of the cryptosystem that we have 
analyzed in [5]). Contrariwise, chaotic systems in discrete time 
are given by a set of difference equations, and their orbits can 
be derived straightforwardly. 

With respect to the security of chaos-based cryptosystems, 
the synchronization techniques entail some critical problems. 
The conditions required for the synchronization of different 
chaotic systems are too demanding and amount to weakening 
the security requirements of an encryption procedure. Cer- 
tainly, 1f synchronization is used as the bearer of an encryption 
architecture, then the chaotic systems at both sides will work 
using a subset of the control parameters space. Assuming that 
the control parameters are the key or part of the key of a 


chaos-based cryptosystem, the matching sensitivity leads to a 
narrowing of the key space, thus lessening the computational 
complexity of a brute force attack [6]-[17]. As a result, chaotic 
systems in discrete time (also known as chaotic maps) are 
better choices when designing new encryption procedures, 
since they possess less computational complexity and can be 
used to construct cryptosystems without synchronization. 

Having as aim the concretion of efficient (and secure) chaos- 
based cryptosystems, it seems that the best option is to select 
the simplest chaotic maps. This being the case, the logistic 
map in particular, and unimodal maps in general have been 
broadly used in the context of chaos-based cryptography [18]- 
[36]. Nevertheless, we point out that unimodal maps cannot 
be applied to cryptography straightforwardly. Indeed, it is 
necessary to examine their potentiality to build up secure cryp- 
tosystems. This analysis is performed through the evaluation 
of chaotic orbits as the kernel of confusion and diffusion of 
the encryption procedure. In this regard a quantification of the 
level of “chaoticity” is required, and we also need to identify 
those situations enabling the estimation of control parameters 
and/or initial conditions from observed information about the 
orbits. 

The rest of the paper is organized towards the above- 
described goals as follows. First, we introduce the basic 
notations used in the following sections. In Sec. III the 
potentiality of achieving information diffusion by concealing 
initial conditions of unimodal maps is studied. The analysis of 
the potentiality for information diffusion also requires to study 
the dependency of the orbits on control parameters, which is 
discussed in Sec. IV. Furthermore, the information confusion 
property is studied in Sec. V by means of different measures of 
entropy for unimodal maps. Finally, the ergodicity of unimodal 
maps is analyzed in Sec. VI, which leads to the final comments 
and conclusions in the last section. 


TI. MATHEMATICAL DEFINITION OF THE SCOPE UNDER 
CONSIDERATION 


Since we are mainly interested in families of (unimodal) 
maps, we define an m-dimensional discrete-time dynamical 
system as a triple (A,14, f), where A € RY is the set of 
parameters, 4 C ¡R”” is the state space, and f: AxU =>U 
is the map that updates the states x € 1 according to the 
rule x > f(A, 2). Since the parameter A is held fixed when 
studying the dynamical aspects, the notation f(A, 1) = f(x) 
will be used. Hence, the rule that transforms an state x,, € U 
into an state 2,1 € U will be written as the difference 
equation Lny1 = fr(2,). Accordingly, the forward orbit 
generated from an initial condition zy € U is 


=p 0 
where 
ifi=0 
1f1>0 


—; Lo, E 
NN 


If the map fr(x) is invertible, then the dynamical system 
(A,U, f) is said to be invertible; in this case, one can also 


pa (2) 
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defined the backward orbits in a similar way. In this paper 
the focus is a specific class of maps, namely, the unimodal 
maps, which are denoted by F. A map f, : U > U, where 
U = [a,b] € R, is unimodal if it is continuous, has a single 
turning point (usually called the critical point) x. in 14, and 
is monotonically increasing (or decreasing) on the left side of 
2. and decreasing (or increasing) on the right side. 

Two different situations are considered in this paper: 

1) The control parameter determines the maximum value 
of the map, being the critical point independent of the 
control parameter. In this case, the parametric function 
fx is given by 

f(x) = AF (0), 6) 


where F € F and F(x.) = Finax. The subclass of maps 
f, € F complying with this description will be denoted 
by Fs. 

As representatives of the map class F1 we consider the 
following three maps: a) the logistic map, defined by the 
rule of evolution 


Tn+1 = Azx,) =A: Tn * (1 = Tn) 


A € [0,4], U = [0,1] (4) 
b) the Mandelbrot map, given by 
tai = xl) = +A, 
A € [-2,0.25),U4 = [-2, 2] (5) 


and c) the (symmetric) tent map, whose difference 
equation is 


fO< zx, <1/2 
m1 = £x(2m) =4 ST / 


f1/2<%,<1, 
(6) 


A: Ln; 


A-(1—2p), 


with A € [1,2], and Y = [0,1]. Strictly speaking, 
the Mandelbrot map is not included in the map class 
F. Nevertheless, the Mandelbrot map is topological 
conjugate with the logistic map [37, p. 529], which 
implies their equivalency by means of their dynamics. 
The critical point is given as a function of the control 
parameter, ¡.e., 1. = F(A). This leads to a new subclass 
of maps F3. 


2 


=— 


In this paper we consider the skew (full) tent map as a 
representative of the map class F2. This map is defined as 


Ln/A, fO<z,<A, 
(1=2.)/(1- A), 5HA<zuw,.<l, 


(7) 
with A € (0,1), and UY = [0, 1]. 


Lai = ÍxlEn) 


TII. MEASURING THE SENSITIVITY TO INITIAL 
CONDITIONS 


Chaotic systems are deemed adequate for cryptography 
due to their high sensitivity to both initial conditions and 
control parameters. With respect to the initial conditions, this 
sensitivity can be measured by the Lyapunov Exponent (or LE 
in short) [38]. In this regard, if a chaotic system is used to im- 
plement an encryption scheme, then the value(s) of the control 


Lyapunov exponent 


Fig. 1. 


Lyapunov Exponent of the skew tent map. 


parameter(s) must be selected in such a way that the maximum 
LE is always positive. Quadratic maps possess a dense set of 
periodic windows in which the maximal LE is not positive 
[39]. This implies an additional complexity in the selection 
Of adequate values for the control parameter(s). Therefore, it 
1s advisable to use a map with a positive maximum LE for 
all the values of the control parameters. In this regard, the 
skew tent map seems to be a good option. Nevertheless, the 
LE of the skew tent map shows a low value for a large set 
of values of A (Fig. 1), which reduces the number of valid 
methods of the information diffusion process built upon the 
orbits of the skew tent map. In other words, we should use 
maps exhibiting robust chaos [40], which can be generated 
from unimodal maps according to the scheme described in 
[41]. Finally, we must emphasize that the computation of the 
LE must be carried out taking into account finite-precision 
arithmetic, which is the real context of digital chaos-based 
cryptography. In this sense, the discrete LE [42] should be 
analyzed and computed. 


IV. STUDY OF THE SENSITIVITY TO CONTROL PARAMETER 


One characteristic of chaotic systems is that their evolution 
in time is sensitive to the vector of control parameter(s) A, 1.e., 
two very close values of A will eventually lead to very different 
orbits after a transient number of iterations. Moreover, this 
difference may be also present when comparing orbits as a 
whole, i.e, from an statistical point of view. In the context of 
chaos-based cryptography, it is highly advisable to avoid any 
kind of dependence of the statistics of the orbits on A. If some 
of the statistics of the orbits can be expressed as a function 
of A, then an estimation of the control parameters could be 
performed. For the sake of clarity, the problem is formulated 
mathematically as follows. Given a chaotic map f, : U =>U 
and a generating partition A = 4AygU A, U...U Ay-1, let 
pi be the probability of visiting the interval 4, is determined 
for 0<13< N— 1. If the statistical behavior of the map 
depends on the value of A, then p; = p¿(A) and the dependency 
of p; with respect to A can be computed using some kind 
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of statistical distance. Here, we give an example based on 
the Wootters” distance [43]. Let us consider two probability 
distributions P, = e E ell with ¿ = 1,2. The 
Wootters” statistical distance is given by 


N 
Dw(Pr, Pa) =cos "1 | Y y/p7 PA]. 68) 
j=1 


If f£, : U >U is unimodal with 14 = [0, 1], then an orbit 
of length M generated from xy € UY can be encoded into a 
binary sequence, 

M-1_ 


Buf, 20) = (Bilfa, 20) Zo 
O) 
where 0(-) is the step function 


0, 
ll 


fy<Zte, 


0(y) íy> te. 


(9) 
A probability distribution can be obtained from By(f, Lo) 
by just grouping all bits in a sliding window of length w. As 
a result, a binary sequence of length M is transformed into a 
sequence of M —w-+1 w-bit integers (or words). The proba- 
bility distribution associated to By (fa, 20) is determined by 
counting the number of occurrences of each word and dividing 
the result by (M — w-— 1). Wootter's distance can be used, for 
example, to estimate the control parameter of the tent map. 
This task is carried out by computing Wootter's distance from 
the binary sequence Br (f;, 0) (generated with an unknown 
value Á of the control parameter) to the binary sequences 
generated with A ranging in an interval. These distances are 
computed in Fig. 2 for two values of A with M = 10% and 
w = 10; the corresponding binary sequences were generated 
with different initial conditions. Figure 2 shows that around 
the right value of A there exists a basin of attraction, which 
leads immediately to an estimation of 2. 

Wootters” distance can also be used to distinguish the binary 
sequences of a unimodal map from those corresponding to 
another unimodal map [44]. As a matter of fact, this is a 
relevant application of statistical distances in the context of 
unimodal maps, since the estimation of the control parameter 
and the initial condition can be performed from binary se- 
quences without any auxiliary tool but the theory of symbolic 
dynamics [45]-[48]. In addition, we must take into account 
that this method is feasible only when the two maps involved 
are not topologically conjugate [37, p. 529]. 


V. ANALYSIS OF CHAOTIC ORBITS AS SOURCE OF 
CONFUSION 


The main appeal of chaos for cryptographic applications 
is based on its random-like behavior. Cryptography achieves 
encryption by embedding the plaintext into a source of entropy. 
Chaos is a source of entropy. Nevertheless, this source of 
entropy is conditioned by the dynamics of the specific chaotic 
system under consideration. Furthermore, there is not only one 
measure of entropies, but a large set of possible measures. In 


Fig. 2. 
w=10. 


[49, Sec. 2.4] we show a set of measures of entropy, and we 
analyze unimodal maps by means of those measures. In that 
work we show that some measures of entropy show a 1-to-1 
or 2-to-1 relationship with respect to the control parameter, 
which could represent a security flaw in the context of chaos- 
based cryptography. 


VI. ANALYSIS OF ERGODICITY 


In this section we point out several different critical contexts 
of chaos-based cryptography where the ergodic behavior of 
unimodal maps causes security problems. 

The first critical context is given by the application of 
unimodal maps to the design of searching-based chaotic 
cryptosystems. The efficiency of searching-based chaotic cryp- 
tosystems is critically dependent on the invariant probability 
density function (PDF) of the orbits of the selected chaotic 
map. The orbits of maps, like the logistic map, the Mandelbrot 
map, and the tent map, possess a non-uniform PDF, which 
implies an important increment of the encryption/decryption 
time. Furthermore, the shape of the PDF of these maps 
depends on the control parameter(s). In some cryptosystems, 
as the one described in [36], the diffusion property is com- 
promised by the dependency of the PDF on the control 
parameter(s). In this sense, we think that the best alternative 
1s the skew tent map, which is a robust chaotic system, 1.e., 
which has a uniform PDF for all the values of the control 
parameter. Nevertheless, schemes like the one in [36] demand 
not only a uniform PDF, but also a high LE. 

The second critical context is the one drawn by encryption 
architectures where the ciphertext is obtained by sampling 
chaotic orbits [26], [50]. In this setting, maps such as the 
logistic map, the Mandelbrot map, and the tent map should not 
be used. Indeed, after a transient time all the values derived 
from the iteration of those maps are inside the interval defined 
by [A(Aíz.)), Lx (z.)] [51], and the histograms of the chaotic 
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Wootters” distance of the tent map with respect to the tent map. The length of the binary sequences is M = 10%, whereas the words are of width 


orbits show peaks located at different images of the critical 
point x. [52]. This means a leak of information about A 
that can be used for its estimation, which implies a serious 
security flaw in the context of chaos-based cryptosystems with 
ciphertext obtained by sampling chaotic orbits [53], [54]. A 
way to avoid this critical context is to select chaotic maps with 
a fixed range for chaotic orbits, which is the case of the skew 
tent map. 

The third critical context is derived from the study of 
ergodicity by means of order patterns. Suppose that the state 
space U/ is endowed with a total order <. Then, the elements 
of the orbits ee (xp) can be arranged from the “smallest” 
to the “largest” according to the relation <. We say that 
x E U defines the order v-pattern T = [mo,71,...,7TT,-1] 
if fla < flo) <...< (2). We also say that z 
is of type rr. Observe that [mo,71,..., Tr, 1] is a permutation 
of the numbers (0, 1,..., 1» — 1). Order patterns can be used 
to detect determinism [55] and, consequently, to distinguish 
random systems from chaotic systems. This being the case, 
the isomorphism between the symbolic dynamics of a chaotic 
map and a random process does not mean an equivalence by 
means of order patterns. Actually, there always exist order y- 
patterns with sufficiently large y that are not realized in any 
orbit of f € F [56]. In Fig. 3 the allowed order-4 patterns 
for the logistic map with A = 4 are shown. For this value of 
the control parameter there exist twelve allowed order patterns, 
which means a divergence from the twenty-four order patterns 
of a random system. 

Another important application of order patterns is parameter 
estimation [57]. In general, if fx is a family of self-maps of 
the closed interval 14 C R parameterized by AEACR (as it 


occurs for f, € F,, 2), and the set P,, is defined as 
Pa =41 EU : x is of type TP, (10) 


where T is an order y—pattern, then P, depends on f, and, 
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Fig. 3. FP (a) for k = 0,1,2,3 and the corresponding order patterns of 
length 4 for the logistic map when A = 4. 


consequently, on A. Moreover, it is assumed that f, is ergodic 
for A CR so that the orbits of f, can be used to build up 
statistics independently from the value of the initial condition. 
According to Birkhoff”s ergodic theorem [58, p. 34], if fx is 
ergodic with respect to the invariant measure ¿u, then the orbit 
of x € U visits the set P, with relative frequency 1 (P,), for 
almost all x with respect to 1. As a result, it is possible to study 
the dependence of P, on A by counting and normalizing the 
occurrences of 7 in sliding windows of width y along YE (2), 
x being a “typical” initial condition. Let us consider the case of 
the skew tent map, which possesses a known ergodic invariant 
measure (the Lebesgue measure) for A € (0,1) [59]. As a 
result, the relative frequency of the order pattern T ina a 
typical orbit of the skew tent map, coincides with the Lebesgue 
measure of P,, which can be determined analytically. For the 
skew tent map, the interval Pio 1... y—1] 18 determined by the 
leftmost intersection of the iterates fX7? and fí7*, where 


m2) =Í 2/N, FO<x<A", 
ATAN AL A AAA 
(1) 
Hence Pjo1....,1-1] = (0, 6L(A)], with 
AL=2 
PL) = 373: (12) 


Since this function is 1-to-1 in the interval 0 < A < 1 for 
L> 2, with d2(0) = 1/2, óx>3(0) = 0, and órsa(1) =1, 
it allows to estimate A by estimating Hb (A) —the length of 
Por... Ly 1571. 

Order patterns can be used for cryptanalysis when we have 
access to the whole chaotic orbit or its symbolic edition. This 
1s the case of the scheme described in [35], where encryption 
is performed through a symbolic sequence of a unimodal 
map. As we have shown in [44], a chosen-plaintext attack 
on the cryptosystem defined in [35] can be used to obtain 
the symbolic sequence used in encryption. If the symbolic 
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sequence was derived from the skew tent map, then the method 
described in [57] can be used to first determine the order 
patterns and second to estimate the control parameter. 


VII. CONCLUSION 


According to the different analysis shown in this paper, 
we conclude that unimodal maps possess a large set of 
vulnerabilities when considering their applications to chaos- 
based cryptography. However, the identification of different 
problems of unimodal maps is very constructive with respect 
to the definition of a framework to design secure and efficient 
chaos-based cryptosystems. This framework helps figure out 
how to avoid those critical contexts. 
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Cifrado de flujo con autómatas celulares difusos 
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Resumen—Este trabajo propone, por primera vez en la li- 
teratura, la utilización del modelo de cálculo teórico conocido 
como “autómatas celulares difusos” para realizar cifrados de 
información. Para ello, creamos nuevos operadores difusos, dise- 
ñamos nuevas funciones locales de transición para los autómatas, 
desarrollamos un software que haga evolucionar los autómatas, 
que realice cifrados de flujo, que cifre y descifre utilizando una 
nueva función real con carácter involutivo, y que compruebe la 
bondad de este nuevo sistema de cifrado mediante diversos tests 
de pseudoaleatoriedad sobre las secuencias cifrantes generadas 
con las evoluciones de los autómatas, y sobre los criptogramas 
obtenidos, y mediante análisis de la correlación entre textos en 
claro y sus criptogramas. 


Í. 


El campo del conocimiento que trata la Criptología es 
prácticamente tan antiguo como la escritura, y ha evolucionado 
junto con el resto de los desarrollos teóricos y de ingeniería 
que el hombre ha ido realizando ([1], [2)). La búsqueda de 
sistemas de cifrado criptográficamente seguros es uno de los 
problemas más interesantes y abiertos que tienen planteados 
conjuntamente las Ciencias de la Computación, el Álgebra 
y la Matemática Aplicada. El enfoque orientado al modelo 
matemático de los autómatas celulares convencionales (no 
difusos) es relativamente novedoso, y proporciona un espacio 
de desarrollo amplio y de múltiples posibilidades. 

Los autómatas celulares son introducidos por John von 
Neumann en los años 60 [3], y reciben un gran impulso en los 
años 80, cuando Stephen Wolfram los utiliza sistemáticamente 
como modelos representativos de sistemas dinámicos ([4], 
[5], [6]). La literatura recoge un autómata celular concreto, 
presentado por Stephen Wolfram en 1986 [5], con el cual se 
implementa un sistema de cifrado muy simple. Durante los 
años 90 y, hasta ahora, se publican multitud de trabajos que 
implementan cifrados basados en autómatas celulares: Howard 
Gutowitz (1993) [7], Nandi, Kar y Chaudhuri (1994) [8], 
Lafe (1996) [9], Sen, Shaw, Chowdhuri, Ganguly y Chaudhuri 
(2002) [10], Amparo Fúster y Dolores de la Guía (2007) [11], 
etc. 

Por otra parte, la teoría de conjuntos difusos o borrosos se 
introduce en 1965 [12], con el célebre trabajo llamado “Fuzzy 
Sets”, de Lotfi Zadeh. Los números difusos empiezan a tener 
importancia con el trabajo de D. Dubois y H. Prade [13], sobre 
variables difusas y el manejo de cantidades imprecisas. Los 
conjuntos difusos fueron aplicados por primera vez en la teoría 
de autómatas por W.G. Wee y K.S. Fu, a finales de los años 
60 [14], dando lugar a los autómatas celulares difusos. 

Los autómatas celulares difusos ya han sido utilizados con 
éxito en aplicaciones para la simulación de sistemas naturales, 
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como, por ejemplo, la expansión del fuego en un bosque, 
y también en aplicaciones para la simulación de sistemas 
artificiales, como, por ejemplo, el desarrollo del tráfico en una 
ciudad, y en otras aplicaciones similares, por autores como 
Mingarelli en 2007 [15], Zhang, Li y Zhao en 2007 [16], Maji 
y Chaudhuri en 2007 [17], Mandelas, Hatzichristos y Prastacos 
en 2007 [18], Maji en 2008 [19], Basu y Basu en 2008 
[20], Yacoubi y Mingarelli en 2008 [21], etc. Sin embargo, 
la aplicación del modelo difuso al ámbito del desarrollo de 
protocolos criptográficos es una cuestión aún no tratada en la 
comunidad científica. 


TT. 


Desde que se definieron por primera vez los autómatas 
celulares difusos por W.G. Wee y K.S. Fu, a finales de los 
años 60 [14], y hasta nuestros días, con investigadores como 
Mingarelli, Zhang, Maji, etc. ([15]-[21])), se han utilizado ha- 
bitualmente tres operadores difusos en los autómatas celulares: 
la suma difusa ( ), el producto difuso ( ) y el complemento 
difuso (), según se definen en el Cuadro I mediante los 
operadores aritméticos convencionales de suma ( ), resta (>) 
y producto ( ), donde y son números difusos: números 
reales del intervalo cerrado 


DEFINICIÓN DE NUEVOS OPERADORES DIFUSOS 


Cuadro I 
DEFINICIÓN DE OPERADORES DIFUSOS CON OPERADORES ARITMÉTICOS 


Operadores difusos | Operadores aritméticos 


Sin embargo, para nuestros propósitos criptográficos, vamos 
a definir dos nuevos operadores difusos, sobre los números 
reales del intervalo abierto : la suma difusa módulo uno 
(), y el complemento difuso módulo uno ( ), mediante las 
Funciones (1) y (2), respectivamente: 


si 
si (1) 
si 
si 


(2) 


Utilizaremos estos nuevos operadores difusos tanto en el 
diseño de funciones locales de transición para la evolución 
de autómatas, como en el diseño de una función real con 
carácter involutivo para el cifrado y descifrado de información, 
que tenga un comportamiento similar a la XOR clásica de los 
criptosistemas de flujo. 


TT. 


En 1917, J. Mauborgne y G. Vernam inventaron el cifrado 
de flujo. Desde entonces, se ha utilizado la función XOR 
(la suma binaria módulo dos) como algoritmo de cifrado y 
descifrado de información. En los años 90 [8], también se ha 
estado usando la función XNOR (su complementaria). Estos 
operadores trabajan sobre números binarios, o sea, se aplican 
bit a bit sobre la secuencia del mensaje (texto en claro), la 
clave (secuencia cifrante) y el criptograma (texto cifrado), y 
tienen la característica de ser involutivas. 

Los operadores XOR y XNOR funcionan muy bien con 
autómatas celulares booleanos [8], pero, en este artículo, 
pretendemos trabajar con autómatas celulares difusos, así que 
uno de nuestros objetivos es encontrar o diseñar una función 

que se aplique en el intervalo real y que tenga este 
comportamiento involutivo: 


DISEÑO DE UNA NUEVA FUNCIÓN REAL INVOLUTIVA 


(3) 


donde . Finalmente, diseñamos la siguiente 
función de cifrado y de descifrado, y comprobamos su buen 
funcionamiento: 


(4) 


donde es cada número difuso del texto en claro, es cada 
número difuso de la secuencia cifrante, es cada número 
difuso del criptograma, es la suma difusa módulo uno, 
y  esel complemento difuso módulo uno, definidos en las 
Funciones (1) y (2), respectivamente. 


IV. DISEÑO DE UNA FUNCIÓN DE CONVERSIÓN DIFUSA 


Los mensajes, las secuencias cifrantes y los criptogramas 
van a ser cadenas de números difusos. Para convertir un 
texto en claro (formado por caracteres ) en una secuencia 
de números difusos, calculamos el grado de pertenencia de 
cada carácter al conjunto difuso de los 256 caracteres ASCH 
mediante la siguiente función que hemos diseñado: 


(S) 


donde es la función que devuelve el valor decimal del código 
ASCII del carácter . Los valores que tiene son los números 
naturales que van desde O hasta 255. 

De esta forma, adquiere valores de números reales equi- 
distantes en el intervalo abierto . Decidimos evitar que 

sea 1, porque ese valor no está definido para la función de 
cifrado descrita en (4). Tampoco vamos a utilizar el O, ya 
que la función de cifrado devuelve el criptograma O cuando 
se usa la clave O para cifrar el número difuso 0 (clave débil). 

Por otra parte, cuando hayamos realizado el descifrado del 
criptograma, y queramos obtener el texto en claro original 
a partir del texto difuso descifrado, aplicaremos la siguiente 
fórmula para calcular el valor decimal del código ASCII de 
cada carácter del texto en claro original: 


(6) 
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[CORRELACIÓN | 


Figura 1. Diagrama descriptivo de los procesos de cifrado y de análisis 


V. DISEÑO DE AUTÓMATAS CELULARES DIFUSOS 


Vamos a trabajar con autómatas celulares unidimensionales, 
y con condición de frontera cilíndrica. Para hacer las pruebas 
iniciales de pseudoaleatoriedad y de correlación, en principio 
hemos parametrizado una longitud del autómata de 128 celdas, 
un tamaño del mensaje de 1000 caracteres (ó 1000 evoluciones 
del autómata), y un radio igual a uno para el vecindario, para 
varias (trece) funciones locales de transición diferentes que 
hemos diseñado y que exponemos en el Cuadro IL, donde ; 
y son la celda anterior, la celda actual y la celda 
siguiente, respectivamente. 


Cuadro II 
DISEÑO DE FUNCIONES LOCALES DE TRANSICIÓN 


Función | Diseño con operadores difusos 
1 
2 0 
3 0 
4 
E) 0 
6 0 
7 
8 0 
9 0 
10 
11 0 
12 0 
13 0 


Los cuatro operadores que se utilizan en estas funciones lo- 
cales de transición son los cuatro operadores difusos descritos 
en el Cuadro I y en la Función (1). El orden de preferencia 
de los operadores es: primero el complemento ( ), después el 
producto ( ) y, por último, las sumas ( ,  ). Estas dos sumas 
tienen la misma preferencia. 

Observaremos, por ejemplo, la primera de las dos celdas 
centrales, para la creación de la secuencia cifrante (hay dos 
celdas centrales, puesto que el autómata tiene longitud par). 
Si no hay presencia de pseudoaleatoriedad en la evolución de 
una de las celdas, difícilmente habrá pseudoaleatoriedad en las 
demás celdas del autómata, debido a las dependencias. 


vi. 


Para comprobar la bondad del nuevo criptosistema, vamos 
a pasar varios tests de aleatoriedad a las secuencias cifrantes 
y a los criptogramas obtenidos: 


Test 1. Chi-Cuadrado para muestras del 50 %: 
[0, 0.5[ y [O.5, 1]. 
Test 2. Chi-Cuadrado para muestras del 25 %: 
[0, 0.25[, [0.25, 0.5[, [0.5, 0.751 y [0.75, 1]. 
Test 3. Chi-Cuadrado para muestras del 10 %: 
[0.0, 0.1[, [0.1, 0.2[, [0.2, 0.3[, [0.3, 0.4[, [0.4, 0.5], 
[0.5, 0.61, [0.6, 0.7[, [0.7, 0.8[, [0.8, 0.91, [0.9, 1.0]. 
Test 4. Frecuencias de los números difusos y 
Test 5. Frecuencias de series de dos números difusos: 


y 
Test 6. Frecuencias de series 


ANÁLISIS DE ALEATORIEDAD Y DE CORRELACIÓN 


El El 


de tres números difusos: 
y 

En los tres últimos tests, denotamos a los números 
difusos del intervalo [O, 0.S[, y a los números difusos del 
intervalo [0.5, 1] de la secuencia cifrante y de la cifrada. 

No vamos a mostrar los resultados del Test 4, porque 
coinciden con los del Test 1, puesto que se cumple la igualdad 
donde se define el cálculo de cada test de aleatoriedad: 


> > > 


E] > 


(7) 


donde es la longitud de la secuencia cifrante, es la canti- 
dad esperada, y donde se cumplen las siguientes ecuaciones: 


(8) 


Por otra parte, para calcular la posible dependencia entre 
textos en claro y sus criptogramas, usaremos el coeficiente de 
correlación de Spearman ( ). 


VII. 


Para probar cada una de las trece funciones locales de 
transición diseñadas, el software (desarrollado en lenguaje 
C++) va mostrando en la pantalla del ordenador todo el pro- 
ceso paso a paso: inicialización pseudoaleatoria del autómata 
celular difuso (con números reales generados por el programa), 
evolución del autómata mil veces, creación de la secuencia 
cifrante, y tests de aleatoriedad sobre la secuencia cifrante, con 
los resultados que se muestran en el Cuadro III, redondeados 
a dos decimales. 

Interesa que los resultados de todos los tests de aleatoriedad 
estén próximos a cero para que haya pseudoaleatoriedad. Para 
una secuencia cifrante de 1000 números difusos, el valor 
máximo de cada test es 1000 para el Test 1, 3000 para el 
Test 2, 9000 para el Test 3, 1998 para el Test 5, y 2331 para 
el Test 6. 

En el Cuadro III, se observa que las seis primeras funciones 
de transición no superan ningún test de aleatoriedad, porque 
tienen estadísticos muy elevados (igual o por encima de mil). 
Esto tiene una explicación lógica: si observamos la evolución 
del autómata en el programa, veremos que todas las celdas 
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Cuadro III 
TESTS DE ALEATORIEDAD SOBRE LA SECUENCIA CIFRANTE PARA LAS 
TRECE FUNCIONES DE TRANSICIÓN DISEÑADAS 


Función | Test 1 Test 2 | Test 3 | Test 5 | Test 6 
1 1000 2992 8980 1997 2331 
2 1000 2992 8980 1997 2331 
3 1000 3000 8980 1997 2331 
4 1000 3000 9000 1997 2331 
5 1000 2992 8980 1997 2331 
6 1000 3000 9000 1997 2331 
yl 0 1000 4000 999 999 
8 1.6 842 3213 847 810 
9 0.68 870 3483 898 879 
10 0.58 2.51 4.24 0.60 3.13 
11 3.36 7.98 13.26 3.49 7.40 
12 0.68 1,27 10.74 0.58 4.03 
13 1,44 2.47 5.44 2.67 2.02 


tienden al estado difuso cero en el caso de las tres primeras 
funciones (que operan con el producto difuso) y al estado 
difuso uno en el caso de las tres funciones siguientes (que 
operan con la suma difusa). 

Las siguientes tres funciones de transición (7, 8, y 9) 
trabajan con el complemento difuso, y podemos observar, en 
el programa, que producen una secuencia cifrante que alterna 
entre ceros y unos, por eso superan el primer test, pero ninguno 
de los demás tests, así que estas funciones no nos sirven. 

Las únicas funciones de transición que superan todos los 
tests de aleatoriedad son precisamente las cuatro últimas 
del Cuadro IL, que trabajan con el nuevo operador difuso 

que hemos diseñado en este artículo. Por consiguiente, 
acabamos de lograr otro de los objetivos del trabajo: diseñar 
alguna función de transición que genere una secuencia cifrante 
que supere los tests de aleatoriedad. De las cuatro, vamos 
a elegir, por ejemplo, para seguir con la investigación, la 
Función 10, que tiene todos los estadísticos por debajo de 
cinco. Para asegurarnos más de la bondad de esta función 
de transición, ejecutamos el software varias (dieciséis) veces, 
utilizando la Función 10 para hacer evolucionar autómatas, que 
se inicializan aleatoriamente en cada ejecución del programa, 
y Obtenemos buenos resultados: todos por debajo de cinco para 
el Test 1, por debajo de ocho para el Test 2, por debajo de 
veintitrés para el Test 3, por debajo de siete para el Test 5, y 
por debajo de quince para el Test 6, según el Cuadro IV. 

El siguiente paso consiste en utilizar las secuencias cifrantes 
que genera el autómata celular difuso con la nueva función de 
transición que hemos diseñado (la Función 10) para cifrar una 
batería de textos en claro, a través de la función real involutiva 
que diseñamos, con la intención de medir la correlación entre 
los mensajes y los criptogramas producidos, y también com- 
probar la aleatoriedad de dichos criptogramas, aplicándoles 
los mismos tests de aleatoriedad que usamos anteriormente 
para las secuencias cifrantes. Para medir la correlación, hemos 
utilizado el coeficiente de correlación de Spearman ( ), y 
hemos seleccionado siete textos en claro diferentes en español 
(filtrados y truncados a mil caracteres). Se trata de los primeros 
mil caracteres de los primeros siete capítulos de la tesis 
doctoral del autor de este artículo. El software que hemos 


Cuadro IV 
TESTS DE ALEATORIEDAD SOBRE LA SECUENCIA CIFRANTE PARA LA 
FUNCIÓN DE TRANSICIÓN 10 SELECCIONADA 


Ejecución | Test 1 | Test 2 | Test 3 | Test 5 | Test 6 
1 1,44 2:22 18.36 6.94 14.12 
2 0.78 1.08 7.14 3.60 5.43 
3 0.48 1:27 9.68 1.02 6.58 
4 0.02 4.4 5.04 0.10 37 
5 0.48 2.42 6.72 0.49 9.37 
6 4.62 79 22.86 6.16 9.85 
7 0.02 3.34 9.42 0.10 7.35 
8 0.68 1.14 13.26 0.69 5.38 
9 0.26 0.74 7.74 0.26 7.59 
10 1.94 1.98 16.06 2.67 7.64 
11 0.1 2.89 15.38 0.37 4.42 
12 0.26 0.54 1.46 0.64 4.47 
13 1.16 1.88 8.14 3.05 2.59 
14 4.62 7,13 16.24 4.37 8.45 
15 0.00 1.94 9.12 0.09 2.26 
16 0.06 2.78 1.28 3.06 4.42 


desarrollado se encarga de ir contando los caracteres de un 
texto mayor hasta alcanzar los mil caracteres que tenemos 
como parámetro, y también de ir realizando un filtrado para 
eliminar caracteres especiales que vayan a causar problemas 
(debido a que no se corresponden con ningún valor ASCH 
entre O y 255). Los resultados se muestran en el Cuadro V. 


Cuadro V 
CORRELACIÓN, Y TESTS DE ALEATORIEDAD SOBRE EL CRIPTOGRAMA, 
PARA SIETE TEXTOS DISTINTOS, CON LA FUNCIÓN DE TRANSICIÓN 10 


Mensaje | Correlación | Test 1 | Test 2 | Test3 | TestS | Test 6 
Texto 1 -0.020697 7.40 8.70 10.74 8.60 19.22 
Texto 2 -0.020510 1.44 3.48 14.28 1.81 13.02 
Texto 3 -0.036655 0.9 4.94 10.92 2.88 5.81 
Texto 4 —0.036660 0.9 2.98 5.42 0.91 6.96 
Texto 5 -0.030538 0.4 3.99 8.5 6.73 15.18 
Texto 6 -0.000387 0.9 4.97 12.44 1.39 7.30 
Texto 7 0.038301 0.58 4.17 13.18 1.31 6.00 


Los resultados del Cuadro V son buenos, porque, para todos 
los textos, el coeficiente de correlación es próximo a cero, y 
todos los tests de aleatoriedad están por debajo de 20, así 
que hemos obtenido otro de los objetivos del trabajo: que no 
hubiera correlación entre mensajes y criptogramas con nuestro 
nuevo cifrado, y que los criptogramas superen los tests. 

Finalmente, el software muestra cómo desciframos cada uno 
de los siete criptogramas con la función real involutiva que 
diseñamos y con la misma secuencia cifrante, obteniendo de 
nuevo los siete textos en claro originales. 

A modo de ejemplo de lo que serían unos malos estadísticos 
en este caso, comprobamos los resultados de cifrar el Texto 
1 con todas las funciones de transición que desechamos, pero 
hay que tener en cuenta que realmente jamás se debe cifrar 
con este tipo de funciones (cuyas secuencias cifrantes no 
superaron los tests de aleatoriedad), sino que esto es sólo 
para observar qué pasaría si lo hiciésemos, y que veamos 
la gran diferencia que hay en los estadísticos: coeficientes 
de correlación próximos a —1 (máximo valor de dependencia 
negativa), y todos los tests de aleatoriedad por encima de 800, 
según se puede observar en el Cuadro VI. 
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Cuadro VI 
CORRELACIÓN, Y TESTS DE ALEATORIEDAD SOBRE EL CRIPTOGRAMA, 
PARA EL TEXTO 1, CON LAS NUEVE PRIMERAS FUNCIONES 


Función | Correlación | Test 1 | Test 2 | Test 3 | Test5 | Test 6 
1 —0.980174 996 1782 2747 1993 2315 
2 -0.977292 996 1782 2747 1993 2315 
3 -0.980032 1000 1789 2758 1997 2331 
4 -0.984420 1000 1789 2743 1997 2331 
9 -0.984200 1000 1784 2743 1997 2331 
6 -0.984420 1000 1784 2743 1997 2331 
7 —0.986696 1000 1789 2743 1997 2331 
8 -0.825714 810 1473 2275 1560 1725 
9 —0.848751 872 1604 2426 1687 1906 


Un aspecto fundamental en los cifrados simétricos es la 
longitud de la clave privada. Hasta ahora, hemos estado 
utilizando 128 números difusos para inicializar los autómatas, 
pero debemos investigar si se pueden obtener secuencias 
cifrantes pseudoaleatorias a partir de claves de menor tamaño. 


Cuadro VII 
MEDIAS DE LOS TESTS DE ALEATORIEDAD PARA 2000 EJECUCIONES 


Clave | Secuencia Test 1 | Test2 | Test 3 Test 5 Test 6 
128 28000 1.00 3.00 9.01 2.01 6.97 
128 18000 1.06 3.10 9.13 2.01 7.19 
128 8000 0.99 2.99 8.93 1.94 6.94 
128 1000 1.06 3.04 9.15 2.03 113 
64 28000 0.98 2.91 8.94 1.96 6.95 
64 18000 1.02 3.14 9.37 2.03 6.97 
64 8000 0.98 3.10 9.12 2.00 7.00 
64 1000 0.97 2.97 8.83 1.98 6.99 
32 28000 0.93 2.90 8.88 1.89 6.93 
32 18000 1.03 3.05 9.18 2.05 7.12 
32 8000 0.99 2.96 8.90 2.00 6.97 
32 1000 1.02 3.10 9.14 2.01 7.03 
16 28000 0.98 2.97 8.97 1.97 6.96 
16 18000 1.04 3.08 9.06 2.00 6.96 
16 8000 1.04 3.12 9.07 2.08 7.10 
16 1000 1.00 3.01 9.08 1.99 6.91 

8 28000 0.99 3.00 8.88 2.02 7.14 
8 18000 1.02 2.98 8.99 2.03 7.14 
8 8000 1.06 3.15 9.18 2.06 6.94 
8 1000 1.00 3.03 9.05 2.01 7.12 
7 28000 0.98 2.94 9.03 2.00 6.93 
7 18000 1.01 3.03 9.04 1.99 6.95 
7 8000 0.98 3.04 8.94 2.00 6.97 
7 1000 1.00 2.94 8.86 1.98 7.01 
6 28000 1.06 3.09 9.07 1052.60 | 746.74 
6 18000 1.01 3.03 9.06 664.25 473.66 
6 8000 0.97 2.97 8.95 294.61 213.56 
6 1000 0.97 2.95 8.85 34.75 30.07 
E] 28000 0.98 2.94 8.99 2.02 7.00 
5 18000 1.01 2.97 8.85 2.00 7.06 
5 8000 1.00 3.05 9.24 1.93 6.99 
5 1000 0.99 3.01 8.99 2.00 7.07 
4 28000 1.01 3.08 9.22 520.24 371.89 
4 18000 1.04 3.06 9.21 334.53 240.79 
4 8000 1.01 3.03 9.02 150.43 111.03 
4 1000 0.98 2.99 8.99 20.63 19.87 
3 28000 2.06 4.68 10.28 3113.34 | 2195.32 
3 18000 2.06 4.55 10.23 2001.53 | 1415.05 
3 8000 2.01 4.51 10.17 891.23 633.65 
3 1000 2.00 4.50 10.24 114.28 85.53 
2 28000 1.00 3.11 9.15 1037.07 735.18 
1 28000 16.08 46.59 | 136.43 — 3138.50 | 2225.31 


Cuadro VIII 
MÁXIMOS DE LOS TESTS DE ALEATORIEDAD PARA 2000 EJECUCIONES 


Cuadro TX 
MÍNIMOS DE LOS TESTS DE ALEATORIEDAD PARA 2000 EJECUCIONES 


Para determinar qué longitud de clave sería la mínima 
necesaria, parametrizamos el programa con distintos tamaños 
de autómata (128, 64, 32, 16, 8, 7, 6, 5, 4, 3, 2, 1) y 
con distintos tamaños de secuencias cifrantes (1000, 8000, 
18000, 28000), y ejecutamos 2000 veces cada combinación 
de longitud de autómata y longitud de secuencia cifrante, con 
diferentes inicializaciones pseudoaleatorias de los autómatas, 
para calcular la media, el máximo y el mínimo de cada grupo 
de 2000 ejecuciones, con los resultados que se muestran en 
los Cuadros VIL, VIII y IX. 

Se obtienen unos resultados excelentes y similares para 
claves de 5 caracteres (o 5 números difusos), y para claves de 
7 caracteres o más (8, 16, 32, 64, 128). Las claves de 6, 4, 3 y 
2 caracteres superan los tres tests Chi-Cuadrado, pero no los 
dos tests de series, así que no nos sirven. Y la clave de un sólo 
carácter no supera ningún test de aleatoriedad. No obstante, 
deberemos continuar la investigación implementando tests de 
aleatoriedad más sofisticados, y utilizando muestras mayores. 
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Clave | Secuencia | Test 1 | Test 2 Test 3 Test 5 Test 6 Clave | Secuencia | Test 1 | Test 2 | Test 3 Test 5 Test 6 
128 28000 16.22 19.69 27.48 16.78 25.32 128 28000 0 0.01 1.07 0.00 0.62 
128 18000 16.81 26.93 30.61 19.33 29.84 128 18000 0 0.01 0.79 0.00 0.53 
128 8000 11.40 21.32 35.27 17.91 28.92 128 8000 0 0.01 0.62 0.00 0.42 
128 1000 11.24 16.34 30.08 19,47 27.34 128 1000 0 0.01 1.02 0.00 0.14 
64 28000 11.85 21.27 31.78 13.78 25.53 64 28000 0 0.01 0.40 0.00 0.26 
64 18000 15.02 17.76 31.16 16.92 34.64 64 18000 0 0.00 0.80 0.00 0.78 
64 8000 11.70 22.49 31.96 14.66 24.92 64 8000 0 0.01 0.96 0.00 0.61 
64 1000 11.66 18.14 28.48 12.70 26.38 64 1000 0 0 1.14 0.00 0.53 
32 28000 13.38 17.15 30.62 13.40 25.55 32 28000 0 0.01 0.52 0.00 0.39 
32 18000 12.59 16.85 29.24 15.30 27.04 32 18000 0 0.01 0.67 0.00 0.20 
32 8000 11.55 20.09 29.79 14,12 30.17 32 8000 0 0.01 0.88 0.01 0.53 
32 1000 12.1 20.78 34.68 14.82 25.41 32 1000 0 0.02 0.96 0.00 0.57 
16 28000 14.00 18.07 30.85 15.27 29.16 16 28000 0 0.02 0.82 0.00 0.62 
16 18000 13.01 17.80 40.13 13.57 24.61 16 18000 0 0.01 0.80 0.00 0.59 
16 8000 14.96 24.88 31.76 17.47 23.30 16 8000 0 0.01 1,31 0.00 0.75 
16 1000 12.1 21.32 29.46 16.73 26.18 16 1000 0 0.06 1.24 0.00 0.43 
8 28000 11.93 17.94 28.99 15.70 33.35 8 28000 0 0.01 0.89 0.00 0.54 
8 18000 13.78 15.58 26.73 17.51 28.01 8 18000 0 0.00 1.10 0.00 0.25 
8 8000 15.66 23.15 32.82 16.13 27.11 8 8000 0 0.02 0.78 0.00 0.35 
8 1000 10 14.90 30.72 14,39 29.45 8 1000 0 0.01 0.98 0.00 0.72 
7 28000 13.20 14.18 26.82 13.75 23.50 7 28000 0 0.00 0.39 0.00 0.63 
7 18000 13.23 21.53 31.54 13.79 23.76 l 18000 0 0.03 0.90 0.00 0.56 
7 8000 14.96 23.81 28.60 15.39 23.87 7 8000 0 0.01 1.03 0.00 0.17 
7 1000 10.82 16.49 33.08 15.12 26.66 7 1000 0 0.01 0.54 0.00 0.43 
6 28000 15.00 20.15 34.64 3339.05 | 2312.48 6 28000 0 0.02 0.37 0.01 56.44 
6 18000 18.95 23.00 34.75 2201.62 | 1534.32 6 18000 0 0.03 0.87 0.03 31.78 
6 8000 20.40 24.89 42.78 1017.66 | 728.36 6 8000 0 0.01 0.85 0.04 11.73 
6 1000 19.6 19.98 36.26 144.27 121.08 6 1000 0 0.02 1.04 0.00 0.96 
5 28000 11.04 15.21 27.91 14,32 31.06 5 28000 0 0.01 0.95 0.00 0.60 
3 18000 14.00 15.78 31.19 15:27 24.37 5 18000 0 0.00 0.79 0.00 0.49 
5 8000 15.66 19.04 28.89 15773 30.52 5 8000 0 0.01 0.89 0.00 0.22 
5 1000 9.60 19.21 33.72 16.40 28.30 3 1000 0 0.01 1:2 0.00 0.48 
4 28000 15.84 21.29 39.62 2918.62 | 2061.69 4 28000 0 0.02 1.20 0.02 3.65 
4 18000 12.48 19.91 31.37 1970.24 | 1401.25 4 18000 0 0.03 1.17 0.01 1.22 
4 8000 14.45 23.51 35.41 860.50 643.23 4 8000 0 0.00 1.01 0.00 1.62 
4 1000 14.4 20.79 34.4 137.12 124.68 4 1000 0 0.02 0.7 0.01 0.72 
3 28000 26.29 33.73 39.76 3560.70 | 2577.08 3 28000 0 0.01 0.81 2686.60 | 1844.76 
3 18000 24.64 28.71 42.32 2247.75 | 1665.27 3 18000 0 0.01 0.60 1718.02 | 1180,92 
3 8000 21.42 27.39 47.12 1066.71 813.25 3 8000 0 0.01 0.49 713.60 472.39 
3 1000 24.34 31.78 42.98 189.62 167.92 3 1000 0 0.01 0.58 48.59 32.05 
2 28000 12.43 24.96 33.53 3300.77 | 2470.18 2 28000 0 0.02 0.87 0.05 51.39 

1 28000 28000 | 84000 | 252000 55997 65331 1 28000 0 0.04 0.66 2803.05 | 1920.97 
VIII. CONCLUSIONES 


Hemos cumplido el objetivo fundamental de este trabajo, 
que consistía en realizar cifrados de flujo utilizando el mo- 
delo de cálculo teórico conocido como “autómatas celulares 
difusos”, y en comprobar la bondad del sistema de cifrado me- 
diante diversos tests de aleatoriedad y análisis de correlación. 

Para desarrollar este criptosistema, hemos tenido que definir 
nuevos operadores de números difusos, diseñar una función 
real en el dominio de los números difusos que tenga carácter 
involutivo para realizar el cifrado y el descifrado (que utiliza 
los nuevos operadores difusos), diseñar una función local 
de transición para autómatas celulares difusos que genere 
secuencias cifrantes que superen los tests de aleatoriedad 
(que también utiliza uno de los nuevos operadores difusos), 
y desarrollar un software (en lenguaje C++) que realiza las 
siguientes tareas: inicialización del autómata celular difuso 
(pseudoaleatoria o con clave introducida por el usuario), 
evolución del autómata con funciones de transición, creación 


de la secuencia cifrante, tests de aleatoriedad sobre la se- 
cuencia cifrante, carga del mensaje (texto en claro), filtro de 
eliminación de caracteres especiales, conversión del mensaje 
a números difusos, comprobación del carácter involutivo de 
funciones reales, cifrado del mensaje con la secuencia cifrante, 
cálculo de correlación entre mensaje y criptograma, tests de 
aleatoriedad sobre el criptograma, descifrado del criptograma 
con la secuencia cifrante, y chequeo de la integridad entre el 
descifrado y el texto original. 

Así que hemos comprobado la utilidad de los autómatas 
celulares difusos en el cifrado de flujo, y la viabilidad técnica 
para su integración e implementación en protocolos criptográ- 
ficos. 

No obstante, deberemos continuar la investigación para 
determinar qué ofrece este nuevo cifrado de flujo, frente al 
habitual en términos binarios, en cuanto a rapidez, seguridad, 
facilidad de implementación software y hardware, longitud 
de la clave, mejores prestaciones, posibles problemas o in- 
convenientes a la hora de su incorporación masiva al mundo 
criptográfico, etc. 
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Resumen—El uso de las curvas elípticas en tarjetas inteligentes 
es vulnerable a los ataques denominados Zero Value Points 
(ZVP), puntos de valor cero. Tales ataques se suelen evitar 
empleando curvas resistentes a los mismos. Para ello, se pueden 
tomar curvas isógenas a la dada inicialmente hasta hallar una 
curva adecuada. En este artículo se plantea una alternativa a este 
método: el uso de curvas de Edwards. Demostramos que tales 
curvas son resistentes a los ataques ZVP. 


I.. INTRODUCCIÓN 


El uso de las curvas elípticas en sistemas criptográficos 
se planteó por primera vez en los años 80 [10], [11]. Desde 
entonces, han adquirido relevancia dado que permiten ofrecer 
altos niveles de seguridad, pero utilizando claves de reducido 
tamaño. Por ello, tienen especial interés en el diseño de 
protocolos criptográficos sobre tarjetas inteligentes u otros dis- 
positivos de capacidad computacional y de memoria limitadas. 

De todos modos, su uso en tarjetas inteligentes no está ex- 
ento de algún inconveniente: su vulnerabilidad a ciertos Side 
Channel Attacks (SCA) [3], [7], cuyo objetivo radica en obten- 
er información de las claves almacenadas en las tarjetas a partir 
de la observación del comportamiento de las mismas, bien sea 
por consumo de tiempo al efectuar operaciones, o consumo 
energético, o incluso comportamiento electromagnético. Exis- 
ten en la literatura múltiples trabajos en los que se analizan 
medidas de seguridad para resistir este tipo de ataques [3], [7]. 

Goubin [9] fue el primero en describir un ataque SCA es- 
pecífico para criptosistemas elípticos. En su trabajo, apuntaba 
ciertas características que deberían tener las curvas elípticas 
escogidas, para que fueran resistentes a estos ataques. Su 
trabajo fue posteriormente ampliado por Akishita and Takagi 
[1], [2], describiendo un ataque (Zero Value Point Attack, 
ZWP) que podrían sufrir aquellas curvas en los que existieran 
cierto tipo de puntos. Hasta el momento, las técnicas em- 
pleadas para resistir estos ataques se basan en el uso de curvas 
isógenas [2], [12], [16]: dada una curva que pueda contener 
puntos vulnerables, se busca una curva isógena a la misma, 
pero que cumpla las condiciones deseadas. La curva isógena 
presentará el mismo nivel de seguridad criptográfica que la 
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original (dado que se mantiene el mismo cardinal), y además 
será resistente a los ataques ZVP. 

Recientemente, H.M. Edwards ha estudiado un nuevo mo- 
delo para curvas elípticas, las denominadas curvas de Ed- 
wards [8], y que presentan una serie de propiedades intere- 
santes [4], [5], [6], [13], [14]. Por un lado, se puede demostrar 
que cualquier curva elíptica sobre un cuerpo no binario es 
birracionalmente equivalente (un cambio de variable dado 
por funciones racionales) a una curva de Edwards sobre una 
extensión del cuerpo y, en muchos casos, sobre el mismo 
cuerpo. Además, las expresiones para la suma de puntos en 
estas curvas son mucho más simples y, en el caso que exista 
un único punto de orden 2, son completas y fuertemente 
unificadas (es decir, se pueden emplear para cualquier par de 
puntos de la curva, y además la misma expresión se puede 
utilizar para el doblado de puntos). 

Posteriormente, D. Bernstein and T. Lange [5] han extendi- 
do la noción de curvas de Edwards, para abarcar una clase 
mayor de curvas sobre el cuerpo original. En su estudio, 
han comparado el comportamiento de las operaciones de 
grupo en estas curvas frente a otras formas y otros sistemas 
de coordenadas, concluyendo que las de Edwards ofrecen 
mayor eficiencia computacional. Además, han mostrado que 
las curvas de Edwards son también compatibles con medidas 
de prevención ante ataques SCA, como son la aleatorización 
de escalares, de coordenadas, de puntos o de curvas. 

En el presente trabajo, nos interesamos por el com- 
portamiento de las curvas de Edwards ante ataques ZVP. 
Mostramos que tales curvas satisfacen ciertas condiciones que 
las hacen resistentes a los ataques ZVP y, por consiguiente, 
utilizarlas resulta una medida preventiva eficiente ante estos 
ataques. 

El artículo está estructurado como sigue: la Sección Il es una 
introducción a las principales propiedades y resultados cono- 
cidos sobre curvas de Edwards; en la Sección III estudiamos 
las condiciones que deben satisfacer las curvas de Edwards 
para ser resistentes a ataques ZVP; finalmente, la Sección IV 
recoge las conclusiones del trabajo. 


II. CURVAS ELÍPTICAS EN FORMA DE EDWARDS 


En 2007, H.M. Edwards [8] definió un nuevo tipo de 
ecuaciones para algunas curvas elípticas; más concretamente, 
toda curva elíptica definida sobre un cuerpo de característica 
distinta de 2 admite una ecuación en forma de Edwards, es 
decir, de la forma 1? + y? = c?(1 + 2?y?). La transformación 
birracional de paso de la forma original a la de Edwards puede 
realizarse en la clausura algebraica del cuerpo base. 

Posteriormente, D. Bernstein y T. Lange [5], con el fin de 
que dicha transformación pudiera realizarse sobre el cuerpo 
base para una familia de curvas elípticas más amplia, ex- 
tendieron esta idea admitiendo un nuevo tipo de ecuación, que 
por similitud también denominaremos de Edwards. Diremos 
que una curva E está en forma de Edwards si tiene por 
ecuación 


2? + y? =c*(1+da*y?) cd(1—c*d) 40. 

Para una tal curva E se puede definir, de manera análoga 
a como se hace para una curva elíptica en forma de Weier- 
trass, una ley de composición. En ella, el elemento neutro 
es (0,c) y dado un par de puntos racionales de la curva 
(21,41), (12, y2) € E la suma se define como: 


11Y2 + Y1T2 Y1Y2 — T]T2 
14 dx122yiy2)' c(l — dx122y1Y2) 


(21,41) +(22, Y2) = É 


Si d no es un residuo cuadrático, esta operación es completa 
y unificada, es decir, las mismas ecuaciones se pueden aplicar 
independientemente de los puntos que se desee sumar y sin 
hacer distinción para sumar dos puntos o calcular el doble de 
un punto (este hecho no ocurre para la suma de puntos en 
curvas elípticas en forma de Weierstrass). 

Además, en estas curvas existen siempre dos puntos de 
orden 4, (c,0) y su opuesto (—c, 0). De hecho, el hecho de 
poseer puntos de orden 4 es una condición necesaria para que 
una curva elíptica sea equivalente a una curva de Edwards. 
Concretamente, más del 25 % de las clases de isomorfía de 
curvas elípticas sobre un cuerpo finito pueden transformarse 
a una curva en forma de Edwards sobre el mismo cuerpo. 
El siguiente teorema [5] muestra qué curvas elípticas son 
birracionalmente equivalentes a una curva de Edwards. 


Teorema 1. Sea k un cuerpo de característica distinta de 2. 
Sea E una curva elíptica sobre k tal que el grupo E(k) tiene 
un elemento de orden 4. 


l. Existe d € k— 10,1) tal que la curva 3? + y? =1+ 
dx?y? es birracionalmente equivalente sobre k a E oa 
una entrelazada cuadrática suya (twist cuadrática). 

. Si E(k) tiene un único punto de orden 2, entonces existe 

un no cuadrado d E k tal que la curva 1? + y? = 

1 + dx?y? es birracionalmente equivalente sobre k a E 

o a su twist cuadrática. 

Si k es un cuerpo finito y E(k) tiene un único punto 

de orden 2, entonces existe un no cuadrado d € k tal 

que la curva x? + y? =1 + dx?y? es birracionalmente 

equivalente sobre k a la curva original E. 


) 
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En el caso en que una curva elíptica sea birracionalmente 
equivalente a una curva de Edwards, existe una corresponden- 
cia entre la ley de grupo de la curva elíptica y la suma en la 
curva de Edwards (Teorema 3.2 en [5]). 


Teorema 2. Sea k un cuerpo de característica distinta de 
2 y sean c,d,e E k* con e = 1— de*. Supongamos que 
d no es un cuadrado y sea la curva de Edwards F : x? + 
y? = (1 + d2?y?). Sea E la curva elíptica de ecuación 
(1/eJu? = u? + (4/e — 2)u? + u. Para cada ¡ € ([1,2,3), 
sean (u;, y;) tres puntos de E tales que (x1,y1) + (22, Y2) = 
(13, y3). Se define P; de la forma siguiente: P; = O (punto del 
infinito) si (x;,y;) = (0,c); P, = (0,0) sí (2;, y) = (0, —c); 
y P, = (u,,v;) si 2, 4 0, donde u; = [c+ y;)/(c — y;) y 
v¡ = 2c[(c + y;)/((c— y;)3;). Entonces 


P; € E(k) P¡ + Pa, = Ps. 


y 


Por tanto, operaciones sobre una curva elíptica dada pueden 
trasladarse a Operaciones sobre una curva de Edwards equiv- 
alente, donde las operaciones son computacionalmente mas 
eficientes. Finalmente, realizando la aplicación inversa, puede 
obtenerse de manera fácil el resultado en la curva elíptica 
original. 


IF-A. Cálculo de la suma y el doblado en una curva de 
Edwards 


En su articulo [5], Bernstein y Lange determinan las fórmu- 
las de las operaciones de grupo en una curva de Edwards. 
Dichas fórmulas, para evitar el cálculo de inversos modulares, 
se realizan usando coordenadas proyectivas (X? + Y?)Z? = 
(2% +dX?Y?). 

El punto (X1 : Y, : Z1), Z1 4 0, corresponde al punto 
(X1/Z1,Y1/Z1). El elemento neutro es (0 : c : 1) y el opuesto 
de (XX Y, : Z1) es (-X; : Y; : Z1). 

Dados dos puntos (Xy : Y, : Z1) y (Xa : Ya : Z2), su suma 
(X3 : Y : Z3) puede obtenerse de la forma siguiente: 


A= 2123, B=4A?, C=X¡X, D = Y¡ Y», 
E=dCD, F=B-E, G=B+YÉ, 


Gi =4F (1 0) =0=D) 
Z3 =cFG. 


Análogamente se calcula el doble de un punto, (X3 : Y3 : 
Z3) = 2(X1 fl Y; ; Z1): 


B=(X, +Y1)", O=Xí, D=YP, 
=D, H=(c2?, J=E-%2BH, 


X3=cB- E)J, Ya =cE(C — D), Za = EJ. 
108 


Como se ha indicado en la introducción, el uso de crip- 
tografía con curvas elípticas en tarjetas inteligentes reveló un 
nuevo tipo de vulnerabilidad. Goubin [9] mostró que un 
atacante podría generar puntos en la curva de manera que, 
tras varios cálculos, alcanzase un punto con alguna coordenada 
nula. En esta situación, el atacante puede obtener información 


ATAQUES BASADOS EN PUNTOS DE VALOR CERO 


de la clave secreta de la tarjeta e incluso todos los bits de la 
misma. Como contramedida, Smart [16] propuso buscar curvas 
elípticas isógenas a la original en las que no existan puntos 
con estas características. Entonces, los cálculos se realizan en 
la curva segura y, utilizando la isogenia dual, se trasladan los 
resultados a la curva original. 

Posteriormente, Akishita y Takagi [1], [2] mostraron que 
este tipo de ataques se pueden extender, no sólo para puntos 
con coordenadas nulas, sino también para valores nulos de los 
registros auxiliares (1.e. los cálculos intermedios necesarios 
para obtener 2P o P + ()). Este tipo de ataque se denomina 
Zero-Value Point attack (ZVP) . Para una explicación más 
precisa véase [1]. 

De igual forma que en el ataque original, es posible encon- 
trar curvas isógenas resistentes al ZVPA. Akishita y Takagi, 
en [2], determinan utilizando únicamente isogenias de grado 
primo, el grado mínimo de una isogenia para encontrar una 
curva isógena segura para las curvas del SECG [15]. En [12], 
los autores utilizan volcanes de isogenias para obtener curvas 
idóneas empleando isogenias de grado mas bajo. 

Como contramedida alternativa, nos planteamos si las 
curvas de Edwards también pueden usarse para evitar 
ataques ZVP. Por ese motivo, estudiamos cuando los pará- 
metros intermedios pueden anularse durante los procedimien- 
tos de suma y doblado. Concluimos que eso sólo sucede para 
puntos que no son criptográficamente interesantes, por lo que 
usar curvas de Edwards en tarjetas inteligentes resulta ser 
seguro contra este tipo de ataques. 

Nótese que tomar curvas de Edwards (cuando esto sea 
posible) será una contramedida más eficiente que buscar curvas 
isógenas ya que este proceso se puede realizar de forma más 
rápida. Por desgracia, el inconveniente es que no todas las 
curvas elípticas tienen una curva equivalente en la forma de 
Edwards. 


IFA. Posibles puntos de valor cero del doblado 


A partir de las fórmulas dadas en la sección anterior para 
el doblado de un punto en una curva de Edwards, el siguiente 
resultado determina las condiciones para que un punto sea un 
punto de valor cero para el doblado. 


Teorema 3. Sea x? + y? = c*(1 + da?y?) una curva 
de Edwards sobre un cuerpo finito con d un no residuo 
cuadrático. Un punto P es un punto de valor cero para el 
doblado si y sólo si P es el elemento neutro de la suma, o es 
un punto de orden 2, 4 u 8. 


Demostración 1. Usando coordenadas proyectivas, sea P = 
(X, : Y, : Z1) el punto a doblar. Los parámetros intermedios 
pueden ser cero si y sólo si alguno de los siguientes valores 
(de las expresiones del doblado) se anulan: 


(X1 + Y1)?, XP, Y?, Xi +Y[,cZ1, E-2H, B- E, C-D 


Nótese que Z1 40 puesto que estamos tratando con puntos 
afines. Si X¡ =0, el punto P sería o bien el elemento neutro 
(0,c) o el punto de orden dos (0, —c). En el caso de que 
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Y, =0, el punto es uno de los dos puntos de orden 4 de la 
curva: (c,0) o su opuesto (—c, 0). 

La condición B— E =0 es equivalente a 0 = (X1+Y,)?— 
De =- y = 2X¡Y;, lo que se reduce a los casos anteriores. 

Si se cumple E—2H = 0, tomando coordenadas afines, se 
tiene que 11 + y? = 2c*; entonces, como el punto pertenece 
a la curva, se concluye que 1 = dx?yi, lo que contradice el 
hecho de que d es un no cuadrado. Similarmente, se alcanzaría 
la misma contradicción si se considerase X? + Y? =0. 

El caso más interesante ocurre cuando (Xy + Y)? o C— 
D= Xi — Y? son cero. En esa situación, el punto afín es o 
bien (21,11) o (21,11). Puesto que 2(x1,—xw1) = (—c,0) 
y 2(11,11) = (c,0), éstos son puntos de orden 8. 

Nótese que existen puntos de orden 8 en la curva si y sólo si 
1—c*d es un residuo cuadrático (esta condición se concluye 
fácilmente al verificar la existencia de puntos (x1,—x1) O 
(11,71) en la curva). 


IHIFB. Posibles puntos de valor cero de la suma 


De modo similar al caso del doblado, el resultado siguiente 
determina las condiciones necesarias y suficientes para que 
un punto P sea un punto de valor cero al calcular la suma 
P+kP. 


Teorema 4. Sea 2? + y? = c?(1 + da?y?) una curva 
de Edwards sobre un cuerpo finito, con d un no residuo 
cuadrático. Un punto P es un punto de valor cero para la 
suma de P y kP = (x2,y2) si y sólo si P es el elemento 
neutro para la suma, o es un punto de orden 2, 4u 8 o 
su orden es un divisor de alguno de los números enteros 


[k,k +1,2k,2(k +1), 4k, 4(k +1),8k). 


Demostración 2. Utilizando coordenadas proyectivas, sea 
P=(X,: Y: 41) el punto sumado a kP = (Xa : Ya : Za). 
Los parámetros intermedios pueden ser cero si y sólo si alguno 
de los valores siguientes (de las expresiones de la suma) se 
anula: 


12, X1X2, Y1 Yo, B E,B E, (Xi | YO | Ya), Y, X3, 


donde (k+1)P =(X3 : Y3 : Z3). 

Puesto que estamos sumando puntos afines, Z1 43 necesari- 
amente será no nulo. Si XX = 0, entonces X, o X3 son 
cero. En el primer caso, P es elemento neutro de la suma, 
o es el punto de orden 2 de la curva. En el segundo caso, o 
bien kP = (0,c) o bien 2kP = 2(0,—c) = (0, c). Entonces 
el orden de P divide a k o a 2k. El caso Y¡ Y, = 0 se puede 
tratar de forma similar, y se obtiene que P es de orden 4 o 
su orden es un divisor de 4k. 

Nótese que B— E y B + E nunca pueden ser 0, en caso 
contrario, tomando coordenadas afines, debería pasar que 
dxwoyiya € (—1,1), lo que contradice la propiedad de 
completitud de la suma sobre la curva de Edwards (Teorema 
3.3 en [5]). 

Si (X1 + Y1)(X2 + Ya) =0, procediendo de forma similar 
que en la demostración del teorema anterior, se obtiene que 
P o kP tienen orden 8. En el último caso, el orden de P es 
un divisor de 8k. 


Si Y3 = 0, o bien nos encontramos en uno de los casos 
anteriores o bien D— C = 0. En esta situación, se obtiene 
que el orden de P es un divisor de 4(k+1), ya que (k+ 1)P 
tiene orden 4. 

Finalmente, si Xz = 0, entonces o (k+1)P = (0,c) o 
(k + 1)P = (0, —c), así que el orden de P es un divisor de 
k+1l0 de 2(k +1). 


Nótese que la última condición en el Teorema 4 es equiva- 
lente al siguiente lema, donde r es el orden del punto P. 


Lema 1. Sea r un primo > 2 y k un entero no negativo 
menor que r. Entonces r es un divisor de alguno de los enteros 


[k, k+1,2k, 2(k+1), 4k, 4(k+1),8k) si y sólo si k =0,r—1. 


Finalmente, a partir de los teoremas 3 y 4, podemos concluir 
que: 


Corolario 1. Las curvas de Edwards son adecuadas para 
implementarse en tarjetas inteligentes que usen criptografía 
de curvas elípticas, porque son resistentes a los ataques ZVP. 


Demostración 3. En criptografía con curvas elípticas, se cal- 
culan múltiplos de un punto (m.P), donde m es un parámetro 
grande. Cuando se implementa en tarjetas inteligentes, es 
necesario garantizar que no aparecerán puntos de valor cero 
durante el cómputo de mP (lo cual se realiza por medio del 
algoritmo de suma y doblado). 

Por motivos de seguridad (para garantizar que el logaritmo 
discreto elíptico no se pueda resolver fácilmente), el punto P 
tiene orden primo r (de hecho r se toma como el primo más 
grande que divide al cardinal de la curva). De ahí, que el 
orden de P nunca será divisor de 8. Además, con respecto 
a las condiciones indicadas en el lema anterior, nótese que 
el caso k = 0 no aparecerá durante el cómputo de mP. Lo 
mismo pasa para la segunda condición porque, en la práctica, 
m será más pequeño que Tr. 

Así, durante el cálculo de mP, el procedimiento nunca se 
encontrará con un punto de valor cero, ni en la suma, ni en 
el doblado. 


IV. CONCLUSION 


Se ha mostrado la idoneidad de las curvas de Edwards 
como base para implementar protocolos criptográficos en 
plataformas con memoria y capacidad de cálculo reducidas, 
como las tarjetas inteligentes, los dispositivos de identificación 
por radiofrecuencia (RFID) o las redes de sensores. 

Dotar a estas plataformas con capacidades criptográficas 
requiere soluciones específicas, que se adapten a tales restric- 
ciones computacionales (lightweight cryptography). 

Las curvas de Edwards proporcionan un modelo alternativo 
de curvas elípticas y los resultados de Bernstein y Lange 
muestran que su aritmética (suma y doblado de puntos) es 
computacionalmente más eficiente que la de los modelos tradi- 
cionales, lo que avala la propuesta de su uso en los dispositivos 
mencionados, con recursos computacionales restringidos. 

Una vulnerabilidad, encontrada en el uso de la criptografía 
elíptica en tarjetas inteligentes, es la posible existencia de 
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puntos de la curva con alguna coordenada nula, o más 
generalmente de expresiones que se anulan en los cálculos 
intermedios necesarios para obtener la suma de dos puntos o 
el doble de un punto, circunstancia que puede ser utilizada por 
un adversario para obtener la clave privada de la tarjeta (Zero 
Value Point Attacks). En el presente trabajo se ha estudiado 
la resistencia a los ZVPA de los criptosistemas basados en 
curvas de Edwards, demostrando su inmunidad a los mismos. 
En efecto, se ha probado que tales curvas poseen pocos puntos 
vulnerables, los cuales además no son criptográficamente útiles 
y por tanto, por razones de seguridad, nunca serían tomados 
en consideración para uso criptográfico. 

En consecuencia, el uso de curvas de Edwards represen- 
ta una buena alternativa, en la implementación de la crip- 
tografía elíptica en tarjetas inteligentes, a las actuales medidas 
defensivas contra los ZVPA (la búsqueda mencionada, vía 
isogenias, de curvas elípticas resistentes). Esta estrategia es 
incluso adaptable a protocolos utilizando modelos “clásicos” 
de curvas elípticas: supuesto un protocolo basado en una tal 
curva elíptica y siempre que esta admita una curva de Edwards 
equivalente (en particular posea puntos de orden cuatro) las 
Operaciones criptográficas necesarias pueden realizarse en la 
curva de Edwards asociada (cuya aritmética es además más 
eficiente) y el resultado obtenido ser finalmente trasladado a 
la curva original. 
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Resumen—Debido a la alta dificultad en resolver el Problema 
de la Palabra en ciertos grupos de Coxeter, es posible utilizar 
a los respectivos grafos de Cayley para desarrollar protocolos 
de identificación del tipo reto-respuesta. Un usuario, digamos 
probador, busca, en efecto, probar ante un verificador que él 
es el titular de una cierta identidad digital. Considerando el 
grafo de Cayley de un grupo de Coxeter en el que el problema 
de la palabra sea intratable, el probador construye su clave 
pública como el conjunto de hojas de un árbol y éste es en 
sí una correspondiente clave privada. En un primer protocolo 
de autenticación, el verificador elige como retos subconjuntos 
de la clave pública y el probador presenta como respuestas 
a los subárboles de una clave privada que tienen a los retos 
como conjuntos de hojas. Cualquier tercera entidad que busque 
suplantar al probador ha de enfrentarse al problema de la 
palabra en el grupo elegido. Aunque este protocolo mantiene a la 
totalidad de la clave privada en secreto, muestra una parte de ella 
al verificador. Presentamos también un segundo protocolo, éste de 
conocimiento nulo, consistente de una transcripción al presente 
contexto del célebre protocolo de este tipo para reconocer parejas 
isomorfas de grafos. 

Términos de índice—Grupos de Coxeter, procedimientos de 
identificación, selección aleatoria de árboles generadores. 


I. INTRODUCCIÓN 


Diversos procedimientos del tipo reto—respuesta han sido 
presentados en la literatura con el fin de autenticar e identificar 
usuarios. Un usuario, o probador, que ha de mostrar ante un 
verificador que posee las credenciales que lo acreditan como 
titular de una identidad digital, puede generar parejas de ins- 
tancias y soluciones de problemas computacionales difíciles. 
Las instancias pueden ser asumidas como claves públicas 
y las correspondientes soluciones como claves privadas [1]. 
El verificador elige instancias del problema, el probador le 
proporciona las correspondientes soluciones y este diálogo 
se repite hasta la plena satisfacción, o convencimiento, del 
verificador. Una tercera parte que busque suplantar al probador 
ha de enfrentarse con el difícil problema de computar las 
soluciones de las instancias planteadas como retos. Entre 
los protocolos de reto—respuesta están los de conocimiento 
nulo [2], los cuales evitan que el verificador “aprenda más 
de lo estrictamente necesario” para convencerse de que el 
probador posee, en efecto, una clave privada correspondiente 
a su propia clave pública. 

Presentamos aquí, primeramente, un protocolo de identi- 
ficación del tipo reto—espuesta basado en la dificultad de 
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resolver el problema de la palabra en grupos de Coxeter. 
En la sección II describimos el protocolo de manera general 
refiriéndonos a un grafo en el que el problema de localizar 
caminos entre parejas arbitrarias de nodos sea intratable (para 
esto es necesario que el número de nodos sea de crecimiento 
superpolinómico respecto a un parámetro de control). 

El problema de la palabra en grupos finitos es, natural- 
mente, resoluble y su complejidad es, en general, polinómica 
respecto al orden del grupo. En la sección HI bosquejamos 
la construcción de los grupos de Coxeter cuyos órdenes 
son superpolinómicos respecto al número de generadores y, 
en consecuencia, sus grafos de Cayley son apropiados para 
realizar el protocolo de identificación introducido. 

Ya que durante el protocolo el probador está presentando 
soluciones al problema de la palabra correspondientes a por- 
ciones propias de su clave privada, dicho protocolo no puede 
ser de conocimiento nulo. En la sección IV presentamos un 
protocolo de conocimiento nulo que permite verificar que el 
probador conoce las respuestas del problema de la palabra 
entre cualesquiera dos nodos en su clave pública sin tener que 
desvelar las soluciones correspondientes. 

A manera de un brevísimo recuento de la influencia de 
la Teoría de Grafos en Criptografía recordamos aquí que los 
grafos expansores han sido utilizados para reforzar funciones 
de hash [3], ha habido esquemas de compartición de secretos 
usando grafos (el tamaño de los fragmentos es proporcional 
a la valencia de los nodos) [4], así como esquemas de 
distribución de claves [5]. Una mención especial la merece el 
uso que se ha hecho de grafos para protocolos de cifrado [6]: 
los nodos de ciertos grafos son mensajes y los cifrados son 
caminos que conectan nodos. 


II. PROTOCOLO DE IDENTIFICACIÓN 


A. Grafos de crecimiento rápido 


Sea K 4 () un conjunto de cardinal k € Z*.Sea f:N > N 
una función de crecimiento al menos lineal, f(n) = Q(n). 
Para un entero n € N, KF( es el conjunto de palabras con 
símbolos en X de longitud f(n). Su cardinal es Ny, = kfim). 

Sea G = (KF("), A) un grafo sobre KF("), Entonces 


2card(A) = y, val(x). 


xek/(m) 


Por tanto, si la valencia de cada nodo fuera al menos d € Z+ 
se tendría card(A) < Nin y la altura de cualquier árbol 
en un bosque generador de G es de orden O(log Ny) = 
O(f(n) log k). En tal caso el problema de localizar caminos 
entre pares de nodos en G puede ser intratable respecto a 
n. Los algoritmos de Dijkstra (en grafos sin ponderación), 
de Prim y de Kruskal (para localizar árboles generadores), 
por ejemplo, que permitirían establecer caminos entre nodos, 
tendrían una complejidad temporal del orden 


O(card(A) + Nin log Nin) =0 ((d+ F9)y 0), 
es decir, exponencial, y por tanto intratable, respecto a n. 


B. Protocolo de identificación 


Consideremos el siguiente escenario de identificación: Un 
probador procura convencer a un verificador de que es el 
titular de la identidad sintetizada, digamos, en una partícula de 
identidad. El verificador le plantea diferentes preguntas como 
retos y, en función de las respuestas que obtiene, decide si 
acaso el probador es el dueño de esa partícula de identidad. 

La partícula de identidad es en sí una clave pública del 
probador y el conocimiento no desvelado que acredita la 
titularidad de la identidad es la clave privada. 

En un grafo de crecimiento rápido, sobre K4() con f(n) = 
Q(n), sea G un subgrafo en donde el problema de localizar 
caminos entre pares de nodos sea intratable, respecto a n. Dado 
un árbol T, es decir un subgrafo conexo sin ciclos, en G, sea 
H(T) el conjunto de sus hojas, es decir de los nodos en T' de 
valencia 1. Evidentemente, el problema de localizar caminos 
entre hojas es trivial para quien conoce el árbol, pero puede 
ser intratable para quien lo desconozca, pues ese problema lo 
es en 6. 

Así, el probador construye un árbol en la gráfica Y y 
publica como su clave pública al conjunto de hojas. Cualquier 
participante que quiera verificar que el probador conoce la 
correspondiente clave privada elige un subconjunto de hojas 
en la clave pública y le requiere un árbol de Y que tenga 
a ese subconjunto como hojas. Evidentemente, el probador 
podrá cumplir de manera eficiente con el requerimiento pues 
la respuesta es un subárbol de su clave privada. 


Protocolo de clave pública 

Precondición. El grafo G debe ser conocido por los parti- 
cipantes en el esquema. 

Inicio. El probador escoge un árbol T' como un subgrafo de 
G. El árbol T' es la clave privada del probador. El 
conjunto A(T') de hojas de T es su clave pública. 

Protocolo de identificación. Repítase 

1) el verificador escoge un conjunto propio N de 
H(T) y lo presenta al probador como reto, 

2) el probador calcula el subárbol Ty de T', tal 
que H(Ty) = N, y le envía Ty al verificador, 

3) el verificador recibe Ty y revisa que en efecto 
H(Ty) = N. Si no se cumpliese esta identidad, 
el verificador rechaza el protocolo, 

hasta el pleno convencimiento del verificador. 
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Debido a que el probador conoce T', podrá responder exito- 
samente en cualquier ronda. Sin embargo, para mantener la 
robustez del protocolo, varias condiciones han de imponerse: 


. el reto N debe plantear una instancia intratable del 
problema de localizar árboles generadores en €, y 

e el reto NV, o la unión de los retos en las rondas del 
protocolo, debe ser un conjunto propio de H(T): de otra 
forma el probador debería desvelar su clave privada. 


Por supuesto, cualquier agente que construya un árbol 7; 
tal que A(T,) coincida con la clave pública del probador 
podría superar exitosamente el protocolo de identificación. La 
construcción de un tal árbol puede resolverse en tiempo lineal 
respecto al número Ng de vértices en el grafo G, pero es un 
procedimiento muy costoso en términos de /g = O(log Ng) 
que es, a su vez, proporcional con el diámetro del grafo UY. 

Aún cuando un intruso que escuche el diálogo entre el 
probador y el verificador conocerá parcialmente la clave 
privada del probador, no podría contestar eficientemente de 
manera correcta en una nueva ronda del protocolo debido a la 
dificultad en localizar caminos en 6. 


TII. EL PROBLEMA DE LA PALABRA Y LA ROBUSTEZ DEL 
PROTOCOLO 


Recordamos que una presentación de un grupo G es una 
pareja (C, R), donde C' es una colección de generadores y 
RC (la = Bl a,f € C*] es una colección de relaciones 
tal que G = F(C)/((R)), donde F(C') es el grupo libre no- 
abeliano generado por C' y ((R)) es el subgrupo normal de 
F(C”) generado por los relatores, es decir, las palabras a87*!, 
con (a = 5) € R. La presentación es finita si tanto C' como R 
lo son. Naturalmente, todo grupo finito posee una presentación 
finita, pero el recíproco no se cumple. 

Por ejemplo para un entero positivo n E ZF, una pre- 
sentación del grupo simétrico S,,, consistente de las permuta- 
ciones en el conjunto [0,n — 1] = (0,1,...,n — 1) de n 
índices, se obtiene con n—1 generadores (tin)¿_y y (n—1)? 
relatores O O donde 


1 silj—=¿=0, 
si |j— 4] > 2. 


De hecho, cada generador t; ha de corresponder a la trans- 
posición (+,1+ 1) de dos índices consecutivos. Así, el grupo 
simétrico S,, de orden n! posee una presentación con (n— 1) 
generadores y (n — 1)? relatores. 


Sea pues G un grupo dado mediante una presentación 
(C,R). El Problema de la Palabra en (E, puesto como un 
problema de decisión, consiste en decidir para una palabra 
o € (CUCT!)* si acaso está o no en el subgrupo normal 
((R)) generado por R en el grupo libre F(C). O, formulado 
como un problema de búsqueda, consiste en que dado yg € G 
se ha de localizar una palabra O, acaso mínima de acuerdo 
con un cierto orden “bien fundamentado” de (CU C72)*, tal 
que yg =0 en G. 


Es bien sabido, desde la década de los 50 del siglo 
pasado, que existen grupos (infinitos) con presentaciones 
finitas en donde el problema de la palabra es irresoluble 
algorítmicamente (Teorema de Novikov). El grafo de Cayley 
de un tal grupo puede servir para implementar el algoritmo de 
identificación presentado en la sección anterior. Sin embargo, 
tal grupo, al ser infinito, es demasiado grande para especificar 
de manera eficiente, desde el punto de vista computacional, el 
subgrafo G que aparece en el protocolo. 

Por otra parte, aunque el problema de la palabra es siempre 
resoluble algorítmicamente en grupos finitos, en la práctica 
puede ser intratable respecto al número n de generadores, 
como es el caso de los llamados grupos de Artin [7]. Recorde- 
mos brevemente su construcción. 

Para dos símbolos x,y y un entero £ € Z*, se denota por 
(xy)” al prefijo de longitud / de la palabra (xy)”, es decir 
(ay) 1 = (2y)l3ln donde y = x si £ es impar y y es la 
palabra vacía en otro caso. 

Sea C un conjunto finito de generadores, es decir meros 
símbolos, y M € (NU[+00))9*C una matriz de orden CxC 
con entradas en NU ([+oo). Las entradas de M son pues 
enteros no-negativos o el valor infinito. Sea Ray la colección 
de relaciones (xy)'""=vl = (ya)'"wel, con (x,y) € CO, 
Entonces (C, Ry) es el grupo de Artin determinado por la 
matriz M. El grupo de Coxeter correspondiente es el que se 
obtiene al añadir las relaciones 1? = 1 (¡.e. Mya = 2). 

El problema de la palabra en grupos de Coxeter tiene una 
complejidad temporal exponencial con respecto al número de 
generadores, n = card(C”), y ha servido como base de diversos 
sistemas criptográficos de clave pública, v.g.: [7]. 

Sea G(n, M) un grupo de Coxeter determinado por la 
matriz M. Posee n generadores y d = ¿(n + 1)n = O(n2?) 
relatores. Sea f(n) = [log,,(o(G(n, M)))] el logaritmo en 
base n del orden del grupo, entonces f(n) = £2(n). Asociando 
a cada elemento en el grupo su expresión mínima como 
una palabra sobre el alfabeto de los generadores, es posible 
representar al grafo de Cayley del grupo G(n, M) con nodos 
en KM), con K =C, tal como se requería en la sección 
anterior al presentar el protocolo de identificación. 

De manera alternativa, sea Hr ((Ray1)) el subgrupo 
normal generado por Ryy en el grupo libre F(C') generado 
a su vez por C. Sea Gy el grafo cuyo conjunto de nodos 
es Hy y las aristas son parejas de la forma (oar,0fBrT) en 
donde bien (a = PB) € Ry o bien ($6 = a) € Ry, es decir 
las reglas de reducción pueden ser aplicadas en uno y en otro 
sentido. El problema de la palabra, que es equivalente al de 
encontrar caminos entre cualesquiera dos nodos, sigue siendo 
de complejidad temporal exponencial respecto a n. 

Cualquier vértice en este grafo se expresa como una palabra 
de longitud a lo sumo f(n) sobre el alfabeto C, por ende 
puede ser representado por una cadena de bits de longitud 
O(fF(m) log n). 

Para utilizar el grafo G yy en el protocolo de identificación, 
un probador ha de construir un subgrafo adecuado Gn de Gm 
y un árbol generador de G,,,, donde m € N es propiamente un 
parámetro del protocolo. 
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Supongamos por el momento que ya se haya construido el 
grafo Gin = (V,, A) con r = r(m) € Z* nodos. Para cada 
nodo v € V;. sea d,, su valencia en G,,. Se va a construir 
un árbol generador siguiendo el procedimiento ya clásico 
presentado originalmente por Broder [8] y por Aldous [9] de 
manera independiente. 

Para cualesquiera dos vértices u,v € V,, sea Puy igual a 
d, * si (v,u) € A e igual a O en otro caso. Se tiene que P = 
(Duo) uvev. es la matriz de transición de una cadena simple 
de Markov en el grafo G,,. Un árbol generador seleccionado 
uniformemente se obtiene de acuerdo con el procedimiento 
siguiente [8]: 


ÁrbolGeneradorUniforme 


1) A partir de un nodo inicial seleccionado aleatoriamente 
vo € V,., sea (LE un paseo aleatorio de una mínima 
longitud que recorra el grafo G,,. Así, para cada u € V,. 
existe un instante mínimo t, < t¿ tal que x,, =". 

Sea T el árbol cuyas aristas son las parejas [x;,-1,U), 
con v € V — [vo]. 

T' es un árbol generador pues consta exactamente de r nodos 
y r— l aristas. Se tiene [8] que t. = O(r?) en peores casos 
en tanto que, por lo general, puede esperarse t. = O(r log r). 
También, bajo ciertas condiciones de regularidad del grafo G,,, 
se puede esperar [9] que la razón entre el número de hojas en él 
y el de vértices queda acotada superiormente por exp (- SS L ), 
así como que el diámetro A(T) del árbol es O(y/r). 

En consecuencia, dado m € N, el probador puede generar 
un árbol, con un número esperado de hojas m, como un 
subgrafo de G yy seleccionando primeramente un grafo conexo 
de r(m) = [ye m] vértices y luego seleccionando uniforme- 
mente en él un árbol generador: 


2) 


ÁrbolGeneradorConNúmeroEsperadoDeHojas 


1) Selecciónese un subgrafo G,, de Gm, con r = [ye m] 
vértices. 

2) Mediante ÁrbolGeneradorUni forme obténgase un 
árbol generador 1” de G,,. 

3) Dése el árbol T' como resultado. 


En el paso 1) de este algoritmo se podría instrumentar un 
recorrido del tipo ““primero-a-lo-ancho” para procurar selec- 
cionar un mismo número de vecinos en cada nodo recién 
“descubierto”, con el fin de satisfacer las condiciones de 
regularidad en [9] para esperar tener efectivamente alrededor 
de m hojas en el árbol producido 7”. Este árbol y su conjunto 
de hojas podrán entonces representarse por cadenas de bits 
de longitud O(m f(n) log n). Así pues, ésta es la longitud de 
los mensajes intercambiados en las rondas del protocolo de 
identificación. 

Es pertinente observar 
anterior construcción podría omitirse elabo- 
rar el grafo Gm. mediante el procedimiento 
ÁrbolGeneradorConNúmeroEsperadoDeHojas. 

A saber: para cada nodo v del grafo de  Cayley 
Gm  considérese una distribución de probabilidad 
(Puv| Lv, u) es una arista en G y), con lo cual Gy viene a 


aquí que en la 


ser una cadena simple de Markov. Dado el entero m € N, el 
árbol T' se produce como en ÁrbolGeneradorUniforme 
mediante un paseo aleatorio que se suspende tan pronto se 
haya visitado [/e m] nodos distintos a pares en Gay. 


TV. PROTOCOLO DE CONOCIMIENTO NULO 


Sea C” un conjunto finito de generadores y sea M € 
(NU [+00 9%“. Sea Gpyr la gráfica de Cayley del grupo 
de Coxeter determinado por M. De acuerdo con los proce- 
dimientos en la sección IM, un probador construye un árbol 
T en Gm, lo asume como su clave privada, y anuncia el 
conjunto de hojas H(T') como su clave pública. Para autenticar 
al probador, un verificador toma un subconjunto J de H(T') 
y se lo presenta como reto al probador quien responde con 
el mínimo subárbol S de T' que tiene a J como conjunto de 
hojas. Así el verificador conoce una parte de la clave privada 
del probador, sin embargo esto no le permite al verificador 
conocer la clave privada por completo. Las rondas reto- 
respuesta podrían reiterarse en tanto los retos no cubran el total 
de la clave pública el probador. Si acaso se recubriese ésta, ya 
sea mediante repeticiones sucesivas de rondas reto-respuesta 
o mediante la colusión de varios verificadores, entonces se 
quebrantaría el esquema de autenticación. 

Presentemos un protocolo modificado, éste de conocimiento 
nulo, similar al que reconoce parejas de grafos isomorfos [2]: 

El probador tiene clave pública H(T”) y clave privada T. El 
verificador conoce pues H(T). 
IdentificaciónConConocimientoNulo 
Repítase 

1) el verificador escoge dos nodos vp,v1 € H(T) y se los 
envía al probador, 
el probador encuentra el camino h que va de uy a uy en 
T, y elige aleatoriamente un punto intermedio va sobre 
h. Sea hy el tramo de h que conecta a vy con va y sea 
h¡ el tramo de h que conecta a v, con vz. Elige un 
camino g en el grafo de Cayley que se inicie en vz. Le 
envía al verificador el nodo final u de ese camino, 
el verificador escoge un bit b € (0,1) y se lo envía 
al probador (con la intención de que éste le muestre el 
camino que conecta al nodo v;, con u), 


2) 


3) 


4) el probador responde con f = gx (hj) [aquí x es la 
concatenación], 

5) el verificador comprueba que, en efecto, f conecta a v, 
con u, 


hasta que falle el probador o el verificador quede convencido. 
Con este protocolo ningún verificador recibe información 
parcial de la clave privada del probador. 


V. CONCLUSIONES 


El primer protocolo de identificación presentado es robusto 
debido al rápido crecimiento de los grafos involucrados ha- 
ciendo intratables los problemas de la palabra y de localización 
de caminos en ellos. Así, las claves públicas no tienen que 
ser demasiado largas, e incluso podrían consistir de un mero 
par de vértices suficientemente alejados pues el problema de 
conectarlos es bastante difícil. Sin embargo, el número de 
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rondas en el protocolo queda restringido por el número de 
hojas que formen una clave pública. Si el conjunto de retos 
recubre la clave pública, el probador habrá de desvelar su 
propia clave privada. Obviamente, en tal caso cualquier intruso 
que la haya capturado podrá cumplir exitosamente con el 
protocolo propuesto. El interés de este protocolo radica en el 
uso de la dificultad del problema de la palabra en gráficas de 
Cayley. El segundo protocolo presentado es de conocimiento 
nulo y sólo calca procedimientos canónicos en este tema para 
proponer un mecanismo de identificación mediante grafos de 
Cayley. 
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Resumen—En este trabajo presentamos un resumen de los 
principales métodos utilizados para la generación de primos 
con particular énfasis en las optimizaciones desarrolladas para 
dispositivos móviles, que suelen disponer de prestaciones com- 
putacionales limitadas. Se presentan, además, los resultados de 
una implementación en Maple del método que consideramos 
más optimizado junto con resultados experimentales de su 
rendimiento. 


I. INTRODUCCIÓN 


En los últimos años hemos asistido a una expansión sin 
precedentes en el uso de la criptografía de clave pública, 
incluso en el ámbito de las relaciones institucionales, como 
es el caso del DNI electrónico y del pasaporte electrónico. 
Estos documentos y otros muchos necesitan utilizar números 
primos (generalmente de gran tamaño) como elementos bási- 
cos para generar las claves o para otros estadios del protocolo 
criptográfico. Resulta, pues, de interés revisar el estado del 
arte en lo que se refiere a los métodos para generar primos. 

Es también un hecho notable la enorme difusión que han 
conseguido dispositivos móviles o portátiles, pequeños pero 
dotados de recursos computacionales más o menos amplios, 
según los casos. Desde teléfonos móviles o PDAs, con alta 
capacidad de cómputo y de memoria, hasta tarjetas inteli- 
gentes, generalmente mucho más modestas en uno y otro 
recursos, todos ellos son ejemplos de sistemas en donde encon- 
tramos con frecuencia capacidades criptográficas. Es necesario 
diseñar algoritmos de generación de primos apropiados a 
estos dispositivos, en cuanto a demanda de computación y 
de almacenamiento. 

En este trabajo presentamos un resumen de los principales 
métodos utilizados para la generación de primos, en dos 
aplicaciones muy populares, GnuPG y OpenSSL, y en dis- 
positivos móviles con prestaciones computacionales limitadas. 
Incluimos, además, resultados experimentales. 

El trabajo se estructura así. La sección II repasa los al- 
goritmos de primalidad deterministas y probabilísticos, con 
especial énfasis en el algoritmo de Miller-Rabin. Las secciones 
II y IV presentan y analizan datos experimentales sobre 
la generación de primos en dos ámbitos diferenciados. Por 
un lado se consideran las aplicaciones GnuPG y OpenSSL, 
sobre plataformas estándar; y por otro, se estudia el algoritmo 
de Joye-Paillier sobre plataformas móviles. Finalmente, las 
conclusiones se presentan en la sección V. 
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II. ALGORITMOS DE DETECCIÓN DE PRIMALIDAD 


Es sabido que decidir sobre la primalidad de un número 
es una tarea mucho más sencilla que factorizarlo, aunque 
los métodos de comprobación de primalidad implican gran 
carga computacional. Ordinariamente se basan en comprobar 
el cumplimiento, por parte del candidato a primo, de ciertas 
condiciones, cuya verificación implica su primalidad. Con 
frecuencia se recurre a métodos que exigen comprobaciones 
menos costosas, pero que, por contra, no dan con toda segu- 
ridad una respuesta correcta, es decir, pueden declarar que un 
número es primo cuando en realidad es compuesto. 

Así pues, se llama test de primalidad (resp. test de composi- 
ción) a un algoritmo que determina que un candidato es primo 
(resp. compuesto). Un test de primalidad decide con total 
seguridad acerca de la primalidad del candidato. Sin embargo, 
el test de composición sólo es capaz de determinar con toda 
seguridad que el candidato es compuesto. Por esta razón, 
a los primeros se les añade el calificativo de deterministas, 
mientras que los segundos se denominan tests de primalidad 
probabilísticos. 


IT-A. Algoritmos deterministas 


El trabajo de Agrawal et al. ([1]) estableció que determinar 
la primalidad de un número admite un algoritmo de primalidad 
determinista de tiempo polinómico, es decir, el problema de 
la primalidad es de tipo P. Sin embargo, el interés de este 
algoritmo es más bien teórico, pues su tiempo de ejecución 


es de O ((ogn)?!1?) en el caso más pesimista, aunque puede 


mejorar a Ó (Cog DN) aceptando ciertas conjeturas habituales. 
La notación O (x) significa O (x-pol(logx)), donde pol(x) es 
un polinomio en x. 

Este algoritmo fue rápidamente mejorado por otros autores, 
entre los que destacan Berrizbeitia ([2]) que baja ese tiempo a 


0) 


1? — 1 es divisible por una potencia de 2 cercana a (Inn). 


Cheng ([3], [4]) extendió ese resultado a una clase más amplia 
de números primos n, aquellos tales que n— 1 es divisible por 
un primo e => (log ny. Bernstein ([5]) generaliza el resultado a 
valores e > (logn)? que dividan a n—1, con d en“ (en la 
práctica, lo interesante es el caso d = 1). Independientemente, 
Avanzi y Mihailescu en [6] generalizaron totalmente el valor e. 


((ogn)*) para aquellos números primos n para los cuales 


Todos ellos son algoritmos de tipo aleatorio que proporcionan 
un tiempo de cómputo esperado de Ó ( (logn)* 

Aunque obtener estos resultados ha supuesto un notable 
esfuerzo, el tiempo de computación de tales algoritmos los 
descarta de un uso práctico y hay que recurrir a los algoritmos 
probabilísticos. 


II-B. Algoritmos probabilísticos: test de Miller-Rabin 


El test de Miller-Rabin es el algoritmo universalmente 
utilizado para producir los llamados «primos industriales». 
Este algoritmo cae en la categoría de test de composición, por 
lo que existe una probabilidad no nula de que el algoritmo 
califique de «no compuesto» un número que realmente lo es. 
Sin embargo, el test permite reducir esa probabilidad a un valor 
tan pequeño como se desee con una eficiencia computacional 
alta. 

El teorema de Fermat es la base de éste y de otros algoritmos 
probabilísticos de comprobación de primalidad y afirma que 
si n es primo y a es un entero tal que mcd(n,a) = 1, entonces 
a”"1=1  (módn). Si se desea comprobar la primalidad de 
n y se encuentra una base prima con n en que el teorema de 
Fermat no se verifica, se puede asegurar que n es compuesto. 
Ahora bien, la recíproca no es cierta: aunque todas las posibles 
bases verifiquen el teorema, eso no garantiza que el número n 
sea primo. A pesar de ello, el test de Fermat en sí mismo es 
extraordinariamente útil por varias razones: 


1. La condición del teorema es sólo necesaria, pero el 
número de excepciones (pseudoprimos) es muy bajo. 

2. Desde el punto de vista computacional depende casi 
totalmente de la exponenciación modular. 

Los números n que satisfacen la congruencia a”! = 1 


(mód n) para toda base a € [2,n— 1] tal que mcd(a,n) =1 se 
conocen como números de Carmichael. Por desgracia, existen 
infinitos de ellos (ver [7]), pero esto no impide seguir usando 
el teorema de Fermat como se verá ahora. 

Si n un número entero impar positivo y a otro entero, 
se escribe n— 1 = 2%, con q otro entero impar. En estas 
condiciones, se dice que n es un pseudoprimo robusto en la 
base a si o bien a7=1  (módn) o bien existe un e tal que 
O<e<sya1=-1 (módn). 

Observación 1: Si p es un primo impar, es fácil ver que 
también p es un pseudoprimo robusto en cualquier base a tal 
que mcd(a, p) = 1. Recíprocamente, se puede probar (véase, 
por ejemplo, [8]) que si p no es primo, existen menos de 
p/4 bases a tales que 1 <a< p para las cuales p es un 
pseudoprimo robusto en la base a. 

Suponiendo que las probabilidades son independientes, es 
claro que si un candidato resulta pseudoprimo robusto para 1 
bases aleatorias, la probabilidad de que sea realmente primo 
será! 1 —272, Con esto, Miller ([10]) y Rabin ([11]) desarro- 


lEsta probabilidad es demasiado pesimista, al no tener en cuenta la distri- 
bución de los primos. Puede verse un análisis más detallado en [9, $$4.48, 
4.49], que proporciona valores adecuados para el parámetro de seguridad de 
acuerdo a la probabilidad deseada. En dicho análisis se demuestra también que 
el parámetro depende además de la longitud en bits del candidato analizado. 
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ENTRADA: 
SALIDA: 


n € Z,, parámetro de seguridad 1 € N. 
n es compuesto o primo probable 
con probabilidad 127”. 


1.  [Inicialización] 
Se eligen s, q €Z tales que n— 1 =2*q, q impar. 
2. [Lazo] 
while (1>0) 
[ Elegimos un entero a € [2,n— 1] aleatoriamente. 
b=a1 (módn); 
if (b== o bien b==n-—1l) goto seguir; 
for (je [l,s—1]) 
[ b=b? (módn); 
if (b==n-—1) goto seguir; 
if (b==1) return “n es compuesto”; 


) 


return “n es compuesto”; 
seguir: 
t=1+-1; 


return “n es primo con probabilidad 1272»; 


Figura 1. Algoritmo de Miller-Rabin 


llaron el test que lleva su nombre y podemos enunciar como 
sigue. 

Algoritmo 2: Dados n € Z, candidato a comprobar, y 1 € N, 
parámetro de seguridad, este algoritmo determina si n es primo 
con una probabilidad de acierto de 1-27”. El algoritmo 
está descrito en la figura 1. 

Es importante ahora tratar del tiempo de ejecución de este 
algoritmo, por estar en el corazón de los generadores de primos 
utilizados en la práctica. De la observación del algoritmo, 
en la figura 1 queda claro que el tiempo de ejecución viene 
dominado por el necesario para llevar a cabo la operación 
de exponenciación modular. Existen muchos algoritmos para 
la exponenciación (véanse, por ejemplo, [12, $1.2], [13, Cap. 
9], [14, $9.3]) que requieren ordinariamente O (logn) multi- 
plicaciones en el grupo. Por tanto es fundamental tratar de 
elegir el método de multiplicar que minimice el tiempo de 
computación. 

Los algoritmos de multiplicación más sencillos requieren 
O ((log ny) operaciones básicas, entendiendo por tales las que 
involucran dígitos de un tamaño máximo, digamos B, en bits. 
Existen otros métodos, sin embargo, que permiten reducir este 
número. 


1. Método de Karatsuba ([15]). Divide los números a 
multiplicar en dos partes más pequeñas, reduciendo 4 
multiplicaciones a 3. Así, el número de operaciones 
básicas pasa a ser O ((logn)23) = O ((logn)!983). 

2. Método de Toom-Cook ([14, $9.5]). Divide los números 


a multiplicar en k partes más pequeñas (si k = 2, se 
convierte en Karatsuba). Cuando, por ejemplo, k=3, el 
número de multiplicaciones pasa de 9 a 5, con lo que el 
número de operaciones básicas es O ((log ny085/ 1085] = 
O ((logn)! 465), 


3. Métodos que involucran transformadas de Fourier, como 
el de Schónhage y Strassen ([16]) que necesita un 


número de operaciones de O (nlognlog?n). 


Todos los métodos citados necesitan realizar aparte las re- 
ducciones modulares, lo que implica costosas divisiones. Ello 
se evita usando la reducción de Montgomery ([17], [18)]), un 
ingenioso método de realizar la reducción modular, que evita 
las divisiones. Este método resulta de mucho interés para los 
dispositivos móviles por su economía, pero ha sido objeto de 
intensos ataques de canal lateral como el timing attack (véase, 
por ejemplo, [19]). Se concluye con la siguiente 

Proposición 3: El tiempo de ejecución esperado para el 
algoritmo de Miller-Rabin es O ((logn)?**). 
El valor de e depende del método de multiplicación empleado. 


TIT. 


En esta sección estudiamos los generadores utilizados en 
dos importantes aplicaciones del mundo del software abierto: 
GnuPG y OpenSSL. Hemos elegido estas dos aplicaciones por 
acogerse a las licencias de tipo GNU General Public License. 

GnuPG es la implementación hecha por GNU de OpenPGP, 
tal como está definido en el RFC4880. Entre las operaciones 
soportadas está, naturalmente, la generación de claves, que 
necesita como base una primitiva de generación de números 
primos. Obviamente, los algoritmos usados para la generación 
impactan en la calidad de los primos generados y, por tanto, 
en la seguridad básica del sistema. 

OpenSSL es un proyecto para desarrollar en código abierto 
una implementación de los estándares Secure Sockets Layer 
(SSL) y Transport Layer Security (TLS), que constituyen la 
base más usada actualmente para la comunicación segura a 
través de internet. Protocolos como https, para navegación 
web con autenticación y cifrado, aplicaciones como ssh para 
comunicación serie (terminal serie) cifrada y autenticada, son 
clientes de tales estándares. También es interesante en este 
caso estudiar y cualificar la calidad de las primitivas de 
generación de primos, base para la generación de las claves. 


GENERADORES EN GNUPG Y OPENSSL 


HFA. Generación en GnuPG 


GnuPG usa GMP, GNU Multiple Precision Arithmetic Li- 
brary ([20]) como biblioteca de multiprecisión?, modificada 
ligeramente en cuanto al modo de almacenar los datos. 

La generación de números primos está centralizada en una 
sola función denominada gen_prime y contenida en el fichero 
cipher/primegen.c de la distribución. 

El proceso de generación implica dos fases: la generación 
de un número aleatorio candidato y la comprobación de pri- 
malidad mediante tests sucesivamente más fiables y costosos 
computacionalmente. En todo el proceso, se utiliza una lista 
estática de números primos hasta e incluyendo 4999, que se 
prepara antes de comenzar el proceso. 


Las bibliotecas de multiprecisión recogen rutinas que permiten utilizar 
datos de precisión arbitraria (por ejemplo, enteros de tamaño arbitrariamente 
grande, o números de coma flotante con precisión arbitrariamente pequeña) 
para lenguajes de programación estándar, como C o C++. En particular, GMP 
es una biblioteca de código abierto, avalada por una amplísima base instalada. 
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1. Fase de generación del candidato: 

a) Genera un número aleatorio. Para ello utiliza los re- 
cursos del sistema operativo; en particular, para los 
sistemas tipo Unix/Linux, el dispositivo urandom. 

b) Asegura que los bits más y menos significativos 
sean “1”. Así garantiza un determinado número de 
bits y que el candidato es impar. 

2. Fase de comprobación de primalidad: 

a) Realiza un test de divisiones sobre la tabla de 
primos bajos. 

b) Realiza un test de Fermat. 

c) Realiza un test de Miller-Rabin, con un parámetro 


de seguridad fijado en 5 para todos los candidatos. 


Si en alguno de los tests de la fase 2 el candidato resulta ser 
compuesto, se repiten los tests sobre el siguiente impar, hasta 
probar un total de 10.000. Si todos los candidatos resultan 
compuestos, se vuelve a la fase 1, se genera un nuevo número 
aleatorio y se repite todo el proceso. 

El algoritmo de exponenciación usado es el clásico de 
«potencia cuadrada y producto repetidos» ([12, $1.2]) junto 
con una reducción por simple división con resto. La multipli- 
cación usa el método de Karatsuba si resulta más eficiente. 


III-B. Generación en OpenSSL 


OpenSSL utiliza una biblioteca propia, incluida en el propio 
paquete, como biblioteca de multiprecisión. Esta biblioteca se 
denomina BIGNUM y está escrita en lenguaje C. 

En este caso, la generación de primos está centralizada en 
la función BN_generate_prime_ex, contenida en el fichero 
crypto/bn/bn_prime.c. Los clientes de esta función son, 
por ejemplo, el generador de parámetros para intercambio de 
claves de Diffie-Hellman, o la generación de claves para RSA. 

En este caso, también la generación de primos comporta dos 
fases: la generación de un número aleatorio y la comprobación 
posterior mediante un algoritmo de primalidad. 


1. Fase de generación del candidato: 


a) Genera un número aleatorio, utilizando funciones 
de la propia biblioteca, basadas grosso modo en la 
familia MD de funciones resumen (hash). 

Dentro de la misma fase, comprueba también 
que el número aleatorio así generado no con- 
tenga ningún factor común con alguno de los 
primos de una tabla de primos estáticamente ge- 
nerada. Dicha tabla está prefijada en el fichero 
crypto/bn/bn_prime.h y alberga los 2048 pri- 
meros primos, desde 2 hasta e incluyendo 17863. 


b) 


Fase de comprobación de primalidad: 


Obtiene un parámetro de seguridad dependiente del 
tamaño del candidato, con el fin de garantizar una 
probabilidad menor de 27% para cualquier número 
de bits que tenga el candidato. Específicamente, se 
elige 3 para los candidatos de 1024 bits, 6 para los 
de 512 bits y 12 para los de 256 bits (véase [9, 
Tabla 4.4)). 


b) Se realiza un test de Miller-Rabin con el parámetro 


de seguridad seleccionado en el punto anterior. 


Como dato de interés, la biblioteca utiliza la exponenciación de 
Montgomery, implementada en la función BN_mod_exp_mont. 


IHIFC. Resultados experimentales 


En esta sección presentamos los resultados experimentales 
acerca de los tiempos de computación y el número de llamadas 
al algoritmo de primalidad que han sido necesarios para 
obtener primos de diversas longitudes utilizando para ello los 
generadores respectivos de GnuPG y de OpenSSL. 

La metodología de trabajo ha sido la misma para las me- 
didas correspondientes a ambas aplicaciones. A continuación, 
resumimos los pasos dados para las mediciones. 


1.  Aislar las rutinas que generan los primos en cada apli- 


cación. 


2. Crear un programa principal como envoltorio capaz de 
generar un primo de la longitud deseada. 
3. Armar una batería de tests que generen 200 números 


primos de longitudes desde 100 hasta 1000 bits, con 
saltos de 100 bits, registrando en cada caso los datos de 
tiempo de ejecución y número de llamadas al algoritmo 
de primalidad. 


Las longitudes se han seleccionado teniendo en cuenta los 
valores que pueden ser de interés hoy en día. Ello no obstante, 
los resultados parecen ser fácilmente extrapolables. Para la 
ejecución de los programas, se ha utilizado una plataforma de 
tipo Intel Pentium M, a 1,60 gHz, con un tamaño de caché de 
2048 kbytes y 1 gbyte de memoria RAM. 

Los resultados experimentales se pueden ver en las figuras 
2-3. La figura 2 representa el tiempo de ejecución necesario, 
medido en milisegundos y representado logarítmicamente, 
frente al número de bits requerido. Hemos representado el 
promedio de tiempos resultado de la batería de tests ejecutada 
para cada una de las aplicaciones, de modo que se pueda ver 
una comparación entre ambas al golpe de vista. Los resultados 
son muy similares si bien se ve que OpenSSL consigue una 
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Figura 2. Tiempo de ejecución promediado frente a número de bits 
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pendiente más suave lo que le favorece para el cómputo de 
números primos más grandes. 

La figura 3 representa el promedio de invocaciones al 
algoritmo de primalidad. Aquí claramente la ventaja es para 
OpenSSL, que consigue obtener primos con menos invoca- 
ciones. Ello se debe a que los candidatos presentados por 
OpenSSL al algoritmo son de «mejor calidad», es decir, tienen 
más probabilidades de ser realmente primos. Sin duda esto 
explica su buen comportamiento en términos de tiempo de 
ejecución, tal como se acaba de ver en la figura anterior. 


IV. (GENERACIÓN DE PRIMOS EN DISPOSITIVOS MÓVILES 


Después de repasar los métodos habituales de generación de 
primos en plataformas estándar, nos centramos en el problema 
de hacer lo mismo sobre dispositivos móviles, tales como 
tarjetas inteligentes, PDAs, etc. Este tipo de dispositivos se 
caracteriza por su limitación tanto en capacidad de proceso 
(que es nula en algunos casos) como en capacidad de alma- 
cenamiento. Ello hace inviables los métodos habituales y hay 
que recurrir a métodos especializados que permitan generar 
primos eficientemente en este tipo de plataformas. Tal es el 
caso del método de Joye y Paillier ([21], [22]). 

La propuesta citada es capaz de producir primos q unifor- 
memente distribuidos en un intervalo prefijado, [4min,qmax], 
donde qmin Y max SON dos enteros arbitrarios, Qin < Qmax- 
Se supone que el dispositivo está dotado de un generador 
de números aleatorios y de una función de comprobación 
de primalidad T. El objetivo es maximizar la velocidad de 
generación, básicamente reduciendo el número de aplicaciones 
del test T, que es lo más costoso computacionalmente. Veamos 
a continuación las distintas fases del algoritmo. 

Selección de los parámetros del sistema. Tomamos 0 <e < 
1 como un parámetro de calidad (por ejemplo, e = 1073) y 
sea Q la función de Euler. Se elige un un conjunto de primos 
y se calcula II =T[[;¡p;, tal que existan enteros f, v, w, que 
satisfacen 
(21-18 < A El 
(P2) vil +1 > qmin; 


> 


ENTRADA: vwt€Z, y ae Zi, (1). 
SALIDA: primo aleatorio en el intervalo [4in, 4 max]. 
1.  [Inicialización] 


Calcular £ = vIl, m = wIl. 
Seleccionar aleatoriamente k € Z; 


m* 


q=|[(k—-t) (módm)] +1 +2; 
2. [Lazo] 
while (T(q)== false) 
[ k=k-a (módm); 
q=|[(k-t) (módm)] +1+0; 
return q; 


Figura 4. Generación de primos de Joye-Paillier 


(P3) (v+w)IH1 +t-=1< UA max> 
(P4) el cociente p(II)/TI es lo más pequeño posible. 
Los primos generados están en el intervalo [vIT ++t,(v+ 
w)IlT++— 1] € [qmin,4max]. De acuerdo a (P1), cuanto más 
pequeño sea e, tanto mejores resultados se obtienen. En (P4), 
minimizar el cociente Q(TI)/TI garantiza que II maximiza el 
número de primos distintos lo más pequeños posible. Dados 
(4min) max, €), calcular los valores de (TI, v,w,t) que satisfagan 
las propiedades (P1)-(P4) es experimentalmente sencillo. 
Generación de primos. El algoritmo se puede ver en la 
figura 4. Es de destacar que el primer paso necesita un valor 
aleatorio k € Z;;,, por lo que hace falta un algoritmo que permi- 
ta la selección computacionalmente simple de unidades. Este 
algoritmo se presenta en la figura 5. También es importante 
destacar que tanto a como k están en el grupo de las unidades 
Z;;,, por lo que siempre son coprimos con II. Aquí radica la 
genialidad del algoritmo: es capaz de generar candidatos a 
primos que excluyen, por construcción, una lista tan grande 
como se quiera y pueda de factores primos (pequeños). Con 
esto disminuye proporcionalmente el número de veces que se 
ha de invocar el test de primalidad antes de obtener un primo. 
Generación de unidades. La clave para el buen comporta- 
miento del algoritmo es la posibilidad de generar fácilmente 
elementos k € Z;, . Para ello, se utilizan los siguientes resulta- 
dos (demostrados o referenciados en [21]). 


ENTRADA: m y A(m), con 4 función de Carmichael. 
SALIDA: unidad aleatoria k € Z;,. 
1.  [Inicialización] 

Seleccionar aleatoriamente k € [1,m]. 

u=(1—k*D)  (módm); 
2. [Lazo] 

while (uX0) 

[ Seleccionar aleatoriamente r € [1,m]. 

k=k+ru (módm); 


u=(1— Am)» 
) 


return Kk; 


(mód m); 


Figura 5. Generación de unidades de Joye-Paillier 
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Proposición 4: Sean m > 1 y k € Zm. Entonces, k € Z;, 

si y sólo si k*(") =1  (módm), donde A es la función de 
Carmichael. 
Recordemos que la función de Carmichael de un número 
n se define como el entero más pequeño, A(n) tal que 
a*(")=1  (módn) para todo a € Z,, tal que mcd(a,n) = 1. 
Sin= 2 ---p;', entonces se puede calcular recursivamente 
como 2 (n) =mcm(A (pj ),...,A(p;')). A su vez, si p>3,0 
s<2,2(p") =0p(p") =p (p-1), y 405) =2?. 

Proposición 5: Sean k,r € Z, tales que mcd(r,k,m) = 1. 
Entonces k+r(1—X*())  (mód m) € Z£,. 

Está claro que calcular la función de Carmichael de mm, 
A(m), es fácil porque, por construcción, sabemos perfecta- 
mente la factorización de m. 


IV-A. Resultados experimentales 


Para obtener resultados de utilización del algoritmo de Joye- 
Paillier no hemos podido contar con dispositivos físicos, por lo 
que hemos recurrido a su implementación en el sistema Maple 
de álgebra simbólica, que es muy popular y proporciona todas 
las primitivas necesarias para ello. No adjuntamos el código 
por falta de espacio. 

La metodología ha sido similar a la utilizada para las 
aplicaciones GnuPG y OpenSSL: el programa implementado 
en Maple es capaz de generar un primo de la longitud pedida, 
reportando el tiempo necesario para ello y el número de 
llamadas al algoritmo de primalidad. Es importante notar que 
los sistemas de cómputo simbólico se ejecutan a una velocidad 
relativamente lenta, por lo que los resultados de tiempo de 
computación son interesantes sólo desde un punto de vista 
relativo. Con la ayuda de este programa, hemos realizado una 
batería de tests para generar primos en el intervalo aproximado 
desde 100 a 1000 bits, en pasos de aproximadamente 100 bits. 
Para cada longitud se generan 500 primos y se registra el tiem- 
po de computación y el número de llamadas al algoritmo de 
primalidad necesarios para obtenerlos. Finalmente se calcula 
el promedio de ambas medidas. 


E A 
ad 
- 0.1 | 
Eb eS 
a 
= PS 
3 
E o0mt  / 
rá 
Y 
0.001 1 1 1 1 1 1 1 1 1 


100 200 300 400 500 600 700 800 900 1000 1100 
Número de bits 


Figura 6. Tiempo de ejecución promediado frente a número de bits 
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Figura 7. Número promediado de invocaciones al algoritmo de primalidad 


Los resultados pueden verse en las figuras 6-7. En la figura 
6 se presenta el tiempo medio de computación. Se observa 
que, en términos relativos, el comportamiento es relativamente 
similar al que se ha obtenido para las aplicaciones GnuPG y 
OpenSSL. Como ya se ha indicado, no fue posible realizar 
estas mediciones sobre dispositivos móviles reales, por lo que 
nos hemos de limitar a señalar el aspecto de la curva. No obs- 
tante pensamos que no es atrevido esperar un comportamiento 
similar. 

En la figura 7 se puede observar que, en general, el número 
de llamadas al algoritmo de primalidad resulta ser más alto 
para todo el rango de tamaño en bits si se compara con los 
resultados obtenidos en la figura 3. Esto resulta en detrimento 
de este algoritmo que precisamente buscaba minimizar el 
número de tales llamadas. Ello parece indicar que el buen 
comportamiento del algoritmo resulta muy dependiente de una 
correcta elección de los parámetros del sistema. 


V. CONCLUSIONES 


En este trabajo hemos presentado un resumen de los prin- 
cipales métodos utilizados para la generación de primos en 
diferentes plataformas. Se ha analizado experimentalmente la 
eficiencia de los métodos utilizados por dos aplicaciones muy 
populares, GnuPG y OpenSSL, así como por el algoritmo de 
Joye-Paillier. Los primeros pueden considerarse de carácter 
general, mientras que el último está especialmente diseñado 
para tarjetas criptográficas con limitada capacidad de cómputo. 

Hemos diseñado programas específicos que aíslan el proce- 
so de generación de primos para cada una de ellas y presen- 
tamos resultados experimentales acerca del tiempo necesario 
y número de invocaciones al algoritmo de primalidad en 
cada caso, considerando la generación de primos con distintas 
longitudes. 

Los procesos de generación de primos, en todos los casos, 
pueden considerarse muy eficientes y los algoritmos emplea- 
dos garantizan una alta calidad en el proceso de generación de 
primos. Este resultado es especialmente destacable en el caso 
del OpenSSL. 
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Aunque no ha sido posible realizar una implementación so- 
bre dispositivos reales, los resultados experimentales aquí pre- 
sentados parecen indicar que el algoritmo de Joye-Paillier 
supone una optimización sobre tarjetas criptográficas, tanto en 
tiempo como en recursos, en línea con las aplicaciones GnuPG 
y OpenSSL, destinadas a plataformas estándares. 
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Un esquema multiusuario de intercambio de clave 
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Resumen—En este artículo se presenta un esquema de inter- 
cambio de clave entre n usuarios que requiere n — 1 envíos 
entre los participantes. Es una generalización del intercambio de 
clave para dos usuarios, y está basado en potencias de matrices 
triangulares superiores por bloques con elementos en Z,. La 
seguridad de este esquema queda garantizada puesto que se basa 
en un problema (bajo ciertas condiciones) intratable como es el 
problema del logaritmo discreto aplicado al grupo de matrices 
mencionado anteriormente. 

Index Terms —1Intercambio de clave, criptografía, matrices por 
bloques, logaritmo discreto. 


I. INTRODUCCIÓN 


Un protocolo de intercambio de clave es aquel por el cual 
dos partes, comúnmente llamadas Alice y Bob, acuerdan una 
clave secreta para el uso en la subsiguiente comunicación 
privada. El intercambio de clave es una parte esencial de un 
sistema de clave pública (véanse [7], [10]). El primer esquema 
de intercambio de clave publicado, fue introducido por Diffie 
y Hellman en 1976 (véase [8]), e independientemente por 
Merkle en 1978 (véase [14]); en él, dos usuarios que quieren 
intercambiar una clave, acuerdan dos valores de entrada del 
algoritmo de intercambio de clave: un número primo grande 
p y un elemento generador y. 

La seguridad del intercambio de clave de Diffie-Hellman 
se basa en la dificultad del problema del logaritmo discreto 
(DLP) sobre cuerpos finitos (véase [6], [11], [13]). Sea G un 
grupo cíclico de orden n y a un generador de G. Si P € G, 
el logaritmo discreto de PB con respecto a a es el elemento 
z E Z, tal que 6 = a”. Como bien es sabido, el DLP para 
G consiste en determinar x cuando G, a: y fP son conocidos. 

Para que el DLP sea útil en la construcción de primitivas 
criptográficas es necesario que el problema sea intratable, 
en otras palabras, no debería tener una solución en tiempo 
polinomial. La intratabilidad computacional del DLP depende 
del grupo cíclico G en el que se esté trabajando [12]. 

En este trabajo se presenta un esquema de intercambio 
de clave entre n usuarios, en el que son necesarios n — 1 
envíos de información, de forma que éstos puedan compartir 
un secreto común y utilizar éste como clave de sesión para 
el cifrado de la información. El esquema presentado utiliza 
matrices triangulares superiores por bloques con elementos 
en Z, (véase [4]) y basa su seguridad en el DLP que surge 
cuando se trabaja con matrices de este grupo. En la sección II 
y como introducción se recuerda el intercambio de clave para 
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dos usuarios. En la sección III se describe la notación utilizada 
con la intención de clarificar la descripción del esquema y en la 
sección IV se presenta, a modo de ejemplo, el intercambio de 
clave para tres usuarios y su generalización para n usuarios, 
así como la demostración de que finalmente comparten un 
secreto. Finalmente, en la sección V, se realiza un análisis de 
seguridad del algoritmo presentado, llegando a la conclusión 
de que el esquema propuesto es seguro, puesto que basa su 
seguridad en el DLP aplicado al grupo especial de matri- 
ces triangulares superiores por bloques. Además, es eficiente 
puesto que se utiliza en todos los cálculos un algoritmo de 
exponenciación rápida (véase [2]) para el mencionado grupo. 


II. INTERCAMBIO DE CLAVE PARA DOS USUARIOS 


Como se ha comentado, el DLP, elegido con un grupo 
cíclico G adecuado, proporciona un nivel de seguridad alto 
a los esquemas criptográficos que lo utilizan. En [3] se 
presenta un intercambio de clave para dos usuarios que basa 
su seguridad en el DLP. El conjunto O sobre el que se aplica 
este intercambio es el siguiente: 

Sea p un número primo y r,s € N; se denota por 
Matrxs(Zp) a las matrices de tamaño r x s con elementos 
en Z,, y por GL,(Z,) y GL;s(Z,) a las matrices invertibles 
de tamaño r xr y sxs respectivamente, también con elementos 
en Zp. Consideramos el conjunto O de las matrices 
A X 
2 3) 
donde A € GL,(Z,), B € GLs(Z,) y X € Matrxs(Z). 

Se tiene, para h un entero no negativo, que 


w- 


Ar x0) 
h 
M" = | 0 ph ; 
siendo 
0, sih=0 
mM. h os 
e NAAA 
i=1 


Se describe, para un par de números zx, y € N, la notación: 


Ao = AA, 
Boy = BiB, 
Cay = APA, 


Liz]-—— acuerdan p, M, y M, «———[B0b] 


le E 
Elige r, s Dd; 3 
[ica] Ba] 
p=[% Cow Elige v, w 
0 Ba, 


K, =A/: LA +. 4 CaB; +X"B, B, 


m2 


aaa == A 
. > kk, 152] 
K, = AJA Xy + ANCEBL + NM "BB." 


Figura 1. Intercambio de clave para dos usuarios 


Si dos usuarios U y V desean intercambiar una clave, deben 
ejecutar el protocolo siguiente: 


1. Acuerdan un número primo p y dos matrices M1, Mo € 
O, con órdenes mi y ma respectivamente. 

2. El usuario U genera dos números aleatorios r,s E N 
tales que 1 < r < mi-1)]1 < s < ma-— 1, 
calcula As, Brs, Cr s, agrupa como bloques en una 
nueva matriz 


Ars 
a=| : 


y envía esta matriz a V. 

3. El usuario Y genera dos números aleatorios v,w E N 
tales que 1 <v < m1 —1,1 < w< ma — 1, calcula 
Avws Buw, Cuw, agrupa como bloques en una nueva 
matriz 


Cos 
Br: 


y envía esta matriz a U. 
4. El usuario U calcula 


Ky = ATA XP + ATC 4 Bl + XV Bio BB 
y el usuario Y calcula 
Ky = AL Ap XX" + APC yo BY + IB B?, 


ocurriendo que Ki, = Ky = K, siendo K el valor de 
la clave compartida. 


Los pasos a seguir para realizar el intercambio de clave con 
dos participantes quedan resumidos en la figura 1. 


III. NOTACIÓN 


A continuación describimos la notación necesaria para rea- 
lizar la ampliación del intercambio de clave a n participantes. 
A) 


Sean las matrices 
Fi X 
| o | 0 Ba | 


Aj Xi 
elementos del conjunto O con órdenes mi y ma respectiva- 


M, = | E 
mente. 
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Se define, para ¿€ [1,...,n), 


A o = APA, 
Be BBs", 
A 


y, para i E [1l,...,nj,k € 42,...,n), utilizaremos la 
siguiente notación: 


k,i ¿ AR—1,i- i 
ARE = APA, 
NA ¿pk-1,i-1 A 
B"" = Bi B ú BS, 
ori pa ARO ABR + ARA L de 


pibas 


siendo r;,s; € N dos números aleatorios generados por el 
usuario U,. 

En el intercambio de clave que se realizará a continuación, 
el exponente k deberá interpretarse como el número de envío 
de información que se realiza, mientras que el exponente 2 
hace referencia al número de usuario que realiza el cálculo, 
siendo ¿ — 1 una manera abreviada de hacer referencia al 
usuario anterior (en vez de (¿— 2 mod n) + 1). 


IV. INTERCAMBIO DE CLAVE PARA n USUARIOS 


El objetivo del artículo es ampliar el intercambio de clave 
presentado en [2] para que participen en él n usuarios. A 
continuación, utilizaremos la notación expuesta en el apar- 
tado anterior para realizar el intercambio de clave para tres 
participantes y, seguidamente, lo extenderemos a n. 

Cabe decir que, cuando se extiende el esquema de intercam- 
bio a más de 2 participantes, todos ellos han de saber cuántos 
usuarios participan en total y en qué orden. 

Sean U;¡, U2 y Uz3 tres usuarios que desean intercambiar una 
clave. Para ello ejecutan el protocolo siguiente: 


1. Acuerdan p primo y M,, M3 € O, con órdenes m; y 
ma respectivamente, así cómo el índice ¿ € ([1,2,3) 
correspondiente a cada participante. 

2. El usuario U¡ genera dos números aleatorios r¡, y sí E N 
tales que 1 < r; <m]—1,1<s, <m2-— 1, calcula 
Abi BA y CH, agrupa estos valores como bloques 
en una nueva matriz 


ADBl 
01 = | A 


y la envía al usuario Uz. 

3. El usuario U2 genera dos números aleatorios ra y s2 € N 
tales que 1 < ra < m1] — 1,1 < s2 < ma2— 1, calcula 
Al? B2 y C*?, agrupa estos valores como bloques 
en una nueva matriz 


act 
Bi1 | 


AS? 
c=|% 


y la envía al usuario Uz. 
4. Por último, el usuario Uz genera dos números aleatorios 
r3 y s3 € Ntales que l < rz3 <m,—1,1< sz <mo-1, 


012 
B12 | 


calcula 41%, B13 y 013, agrupa estos valores como 
bloques en una nueva matriz 


1,3 
0! = | a 


y la envía al usuario U;. 

5. Utilizando los bloques de la matriz que ha recibido de 
Uz, el usuario U, calcula 42*, B21 y C?1, agrupa estos 
valores como bloques en una nueva matriz 


A?! c21 
Ci = | 0 B21 | 


y envía esta matriz a Uz. 

6. De manera análoga, el usuario Uz calcula 4?!, B?2 y 
022, agrupa estos valores como bloques en una nueva 
matriz 


013 
Bi13 | 


A?2? 
ci=| 
0 
y envía esta matriz a Uz. 
7. El usuario Uz calcula 42%, B23 y C23, agrupa estos 
valores como bloques en una nueva matriz 
2 A?253 023 
q 0 B2,3 


y envía esta matriz a U;. 
8. Los tres participantes U¡,U2 y Uz calculan 


(022 
B2,2 | 


Kg, = APOPBRG ADA 
XxX) g23 pg, 
Ki = APOPBRLAPARA 
x("2 p21pg 
y 
Kv, = AROS AA 
x(1) p22 pgs, 


ocurriendo que Ky, Ku, Ku, K, que es la 
clave compartida, como se demostrará más adelante. 


A continuación se generaliza el intercambio para el caso en 
el que participen n usuarios. 

Sea n E N, y sean U,,i € ([1...n), interlocutores que 
desean intercambiar una clave. Para ello ejecutan el protocolo 
siguiente: 

1, Acuerdan un número primo p y M¡,M2 € O, con 
Órdenes m, y ma respectivamente, así cómo el índice 
1€ (1...n) correspondiente a cada participante. 

2. Cada participante U, genera dos números aleatorios 7; 
y sí; EN tales que l <r, <m¡—1,1<s;, <mo2-— 1. 

3. Repetir, desde k = 1 hasta k =n—1 
3.1 Cada usuario U; calcula 4**, B*+ y C** y agrupa 

estos valores como bloques en una nueva matriz 
| MOL |] 


k-= 
Gp Br 


2 


(1) 
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3.2 El participante U; envía esta matriz CF al usuario 
siguiente, esto es, el usuario U; envía or al usuario 
U;, siendo j = (i mod n) +1. 
4. Utilizando la última matriz recibida, cada participante 
U; calcula 


AaporLiL as AD CES de 
A BABES == K, 


Ky, = 


que es la clave compartida. 
El teorema siguiente muestra que la clave es común a todos 
los participantes. 
Teorema l: Ky, = Ky, , =K,1=2...Nn. 
Proof: Para ¿=2...n, sea P, = M¡'*M)5*, con 


ri (rs) Si (54) 
mp=| 4 XA [ymp=|4 %|, 
0 Bi' 0 B3 
y sea 
Ae a Au, Kv, | 
Mu, = Mi*P,-1M5* = E ls 
Us 1 18 | 0 Bu, 


Con esto se tiene que 


Mu, = Mi*P,-1M5* 
= MM M3" M5 
= MMMM > 
= Mi "Pi MM > 
My,_, 
y, consecuentemente, Ky, = Ky, ,,1=2...N. Mm 


El teorema que se muestra a continuación explicita la forma 
de la clave compartida. 

Teorema 2: La clave que se comparte con el intercambio 
descrito tiene la forma 


ARO Lp +A an=Lii y les de 
Xx go-Li gas 


Ku, = 


Proof: Se demuestra por inducción sobre k, siendo k el 
número de envío. 

Para k = 2. El usuario U;_1 calcula 4471, BLI71, 
ChI=1, agrupa los valores como en (1) (con k = 1) y envía 
esta matriz a U;. 

U; calcula 


M C¡ M7 = 


AY x02) ALj=1 qua AS x (9) Ñ 
O Bi 0 Br D BE o 
AN ALi-1 AROMA 4 aia AS a 
0 B Buil 0 BS 
A?Í 02) 2 
| o  B?i | es 


donde 
Ca — AT Abó=1 (03) + (APO 4 X 00 pli-1) ps 


y, por tanto, para k = 2 el bloque superior derecho tiene la 
forma indicada. 

Supongamos ahora que el bloque superior derecho de las 
matrices que se mandan en el envío n — 1 tienen esa forma, 
y veamos que la que se forma a partir de ellas (cuyo bloque 
superior derecho es la clave compartida) también la tiene. 

Sea entonces 


n-—1,j-1 
Jl 0 


cn-1,j=1 
pgnroti-=1 


la matriz calculada por el usuario U;_¡ para realizar la 
comunicación n — 1. Este la envía al usuario siguiente, Uj, 
que calcula 


Mi? 5 MO? pe 
A x(09 pn-1,j-1 ada AS xn 
0 BP 0 gn=tj-=1 0 Bs 
APA AAS lo 
0 BO grobi-1gs [> 
siendo 
Ky, = Aj pr=1 4-1 x (80 7 (gmoa=Lj1 y 


Xx) ga=Lj-1) pss 


la clave compartida, que tiene la forma indicada. 


V. ANÁLISIS DE SEGURIDAD 


Para evitar ataques por fuerza bruta, el orden de M; y Ma 
tiene que escogerse suficientemente grande (del orden de 1024 
bits). 

El algoritmo de Menezes y Wu [13] es una técnica común 
para analizar la seguridad de esquemas de clave pública en 
los que intervienen potencias de matrices. Básicamente, este 
algoritmo establece la posibilidad de reducir el problema del 
logaritmo discreto a una serie de logaritmos discretos sobre 
un cuerpo finito de pequeño tamaño F¿m,, donde my, es el 
grado del polinomio irreducible, que es un factor del polinomio 
característico de la matriz A. La entrada de este algoritmo es 
una matriz cuadrada, como A, B € GL,,(Z,) con B = A, y la 
salida es el exponente entero /. Así pues, este algoritmo puede 
ser efectivo contra esquemas que hacen públicas potencias de 
matrices cuadradas. Sin embargo en el esquema presentado 
sólo se hacen públicas las matrices CF, lo que hace inviable 
este tipo de ataques. 

Climent, Gorla y Rosenthal [5] proponen una técnica de 
ataque basada en el teorema de Cayley-Hamilton, que es 
susceptible de ser usada en esquemas donde aparecen matrices 
triangulares superiores por bloques. Este ataque está basado 
en la existencia de un único polinomio característico, lo cual 
invalida su utilización en el esquema presentado, ya que se 
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usan dos matrices Mi y M2 con polinomios caracteristicos 
diferentes. 

González, Pérez y Taborda [9] realizan un análisis para 
el intercambio de clave de dos usuarios habiendo realizado 
una reducción del problema a una extensión del cuerpo base, 
llegando a la conclusión de que el esquema matricial no 
presenta ventajas con respecto a la computación en dicho 
cuerpo. Esto último condiciona la elección del primo p de 
manera que el DLP sea lo suficientemente duro. 


vi. 


En este artículo se ha descrito un esquema de intercambio 
de clave entre mn usuarios en el que son necesarios n — 1 
envíos de información. El esquema presentado se basa en un 
intercambio de clave para dos usuarios que utiliza un grupo 
especial de matrices triangulares superiores por bloques (con 
unas excelentes propiedades criptográficas). El intercambio de 
clave propuesto, basa su seguridad en el DLP aplicado al 
citado grupo de matrices. Además es un protocolo eficiente, 
puesto que se utiliza un algoritmo de exponenciación rápida 
para matrices por bloques. 


CONCLUSIONES 
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Abstract—Identity-based non-interactive key distribution (ID- 
NIKD) is a cryptographic primitive that enables two users to 
establish a common secret key without exchanging messages. All 
users of the system have access to public system parameters 
and a private key, obtained through the help of a trusted key 
generation center. 

In this contribution, we discuss how to capture an intuitive 
form of forward security for ID-NIKD schemes in a security 
model. Building on results of Sakai et al. as well as of Paterson 
and Srinivasan, we discuss how the proposed notion of forward 
security can be achieved in the random oracle model, using 
a Bilinear Diffie-Hellman assumption in combination with a 
forward-secure pseudorandom bit generator. 


IT. INTRODUCTION 


Identity-based non-interactive key distribution (ID-NIKD) 
has already been discussed by a number of authors — including 
work by Blom [3], Matsumoto and Imai [5], Tsujii et al. 
[10], Maurer and Yacobi [6], [7], and Dupont and Enge [4]. 
Starting point for our work is the security model for ID- 
NIKD proposed by Paterson and Srinivasan [8], specifically 
the following comment in the latter paper: we note that no 
non-interactive key distribution scheme can meet the notion 
of forward security that is enjoyed by many interactive key 
distribution protocols. Subsequently we explore the question 
of achieving forward security, by passing from an “ordinary” 
ID-NIKD scheme to a primitive to which we refer as key 
evolving ID-NIKD, which is in line with the key evolution 
paradigm as discussed for signatures by Bellare and Miner 
[1]. 

After recalling the relevant technical definitions in the next 
section, in Section HI we provide the definition of a key 
evolving ID-NIKD along with a security model, capturing 
forward security. Thereafter, we discuss how a combination 
of a forward-secure pseudorandom bit generator with an ID- 
NIKD scheme by Sakai et al. [9] can be used to achieve 
forward security in the sense we defined it. 


TI. PRELIMINARIES 


On the cryptographic side, a main technical tool we need 
is a forward-secure pseudorandom bit generator and, building 
on Sakai et al.'s proposal, we also make use of pairings. 
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A. Stateful pseudorandom bit generators 


For the relevant facts on pseudorandom bit generators, we 
follow mainly the exposition of Bellare and Yee [2]. 

Definition 1 (stateful pseudorandom bit generator): A 
stateful generator GEN = (GEN.key, GEN.next, b,m) is a 
tuple of polynomial time algorithms as follows: 


+. GEN.key is probabilistic, and on input the security 
parameter outputs the initial state (seed). 

+ GEN.next is deterministic, and given the current state 
St; outputs a pair (Out;+1, St,,1), where Out;y1 is a 
b-bit string and St;,1 is the next state. 

e bis the size of the output blocks. 

+ mis the maximum number of output blocks the generator 
may be used to produce. 


In order to achieve forward security of a generator as specified 
in the above definition, we require that every time the generator 
outputs a pair (Out;, St¿), the previous state St;_/ is erased, 
so that an adversary breaking into the system is only able to 
learn the current state. 

Definition 2 (forward secure pseudorandom bit generator): 
A stateful generator GEN is forward-secure if the advantage 
of any probabilistic polynomial time adversary A attacking 
GEN as described in Figure 1 is negligible. For this, the 


advantage of A is defined as Adv¿Exó(A) = 
¡Pr[Expcen” (4) = 1) — PrExpcen” (4) =1]| 


In other words, we require the outputs generated in the 
past by the stateful generator to be computationally indistin- 
guishable from (true) random bits. The adversary can decide, 
depending on the output blocks it has seen, when to “break 
in”, 1.e., to try to distinguish the generator's output from a 
true random source. During the find stage ( A(find, Out, h)), 
every time A receives an output block, it outputs a pair (h, d), 
where h is the updated history and d indicates if .4 prefers to 
remain in the find stage or rather wants to guess if the outputs 
have been generated by the generator (Experiment 1) or are 
random strings (Experiment 0). 

In [2] Bellare and Yee show how to build a forward-secure 
stateful generator from a secure standard pseudorandom bit 
generator and from number-theoretic assumptions. 


fsprg—1 
GEN 


Experiment Exp 
Sto £- GEN.key 
10; h+e 
Repeat 
1 1+1 
(Out;, St;) + GEN.next(St;_1) 
(d,h) € A(find, Out;, h) 
Until (d = guess) or ¿=m 
y pul A(guess, St;, h) 


(A) 


fsprg—0 
GEN 


Experiment Exp 
Sto £- GEN.key 
10; h+e 
Repeat 
1 1+1 
(Out;, St;) + GEN.next(St;_1) 
Out; € £0,1p 
(d,h) € A(find, Out;, h) 
Until (d = guess) or ¿= m 
Y E A(guess, St;, h) 


(A) 


Return y 
Return y 
Fig. 1. Attacking forward security of a stateful generator 
B. Pairings Definition 5 (key evolving ID-NIKD): A key-evolving non- 


For the relevant terminology on pairings, we follow mainly 
Paterson and Srinivasan [8]. 

Definition 3 (pairing): Let G be an additive group and Gry 
a multiplicative group, both of primer order q. Denote by P 
a generator of G. A pairing is a map e: Gx G —> Gr with 
the following properties: 

e Bilinearity: For all Q,R € G and for all a,b € 

([1,...,q — 1) we have e(aQ,bR) = e(Q, R)”. 
. Non-degeneracy: e(P, P) H 1. 
+. Computability: There is a probabilistic polynomial time 
algorithm to compute e(Q, R) for al Q,ReG 

Note that the map e is symmetric, since e(aP,bP) 
e(P.PI*=e(BP. aP) 
To express the hardness we want to use in the protocol 
discussed below, we need a generator algorithm PairingGen 
that on input the security parameter 1% outputs, keeping the 
above notation, a tuple (G, Gr, e, q, P) with q > 2*. 

Definition 4 (BDH): Given a generator  algorithm 
PairingGen as just described, for a probabilistic polynomial 
time algorithm .A we define the advange of A in solving the 
Bilinear Diffie-Hellman problem (BDH) as 


Advbé*(k) = Pr(A(aP, DP, cP) = e(P, dla 


where a,b, c ps [0,...,q—1) are chosen uniformly at random. 

If Advef" is negligible for all probabilistic polynomial time 
algorithms .4, we say that the BDH assumption holds for 
(G, Gr,e) (or, more precisely, for PairingGen). 


TIT. KEY-EVOLVING NON-INTERACTIVE KEY 
DISTRIBUTION 


Building on the definition of an “ordinary” identity-based 
non-interactive key distribution scheme used in [8], we suggest 
the following notion of key evolving 1D-NIKD, allowing a non- 
interactive key distribution scheme to have algorithms that 
compute a secret key of a time period taking as input the 
secret key of the previous one, both for the central authority 
and the users. Every time the time period changes, the previous 
secret key used as input is erased. 
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interactive key distribution scheme is a quintuple of polyno- 
mial time algorithms as follows: 


Setup is probabilistic and run by a central authority. 
Given the security parameter 1% and a total number 
of time periods N € N, Setup generates an initial 
master secret key mk? of the central authority, along with 
the public parameters params. The public parameters 
include the description of the private key space SIC and 
the shared key space SHK. 

MasterKeyUpdate is deterministic and run by a central 
authority. Given the public parameters params and the 
master secret key mk'=! of the previous period it gener- 
ates the master secret key mk* of the current period and 
deletes mk'*"!, 

KeyExtract is probabilistic and run by a central authority. 
Given the current master secret key mk?*, the public 
parameters params and an identifier ID € (0,17%, it 
generates a secret key Sí, from the private key space 
SK. 

KeyUpdate is deterministic and run by a user. Given the 
public parameters params and the secret key a of 
the previous period, it generates the secret key 55, of 
the current period and deletes Ci 

SharedKey: is deterministic and run by a user. Given 
the public parameters params, the secret key 5% Da of 
the current period for an identity /Dx and an identifier 
IDg € [0,1)*, SharedKey generates a key K*, y from 
the space of shared keys SHXK specified in params. 


We require that for any identities /D 4, [Dg and correspond- 
ing private keys S1p,, S1p and for any period ¿, SharedKey 
satisfies the constraint 


SharedKey(params, Sp, , 1D) 


Sharedkey (params, SiDa IDA). 


This ensures that the users corresponding to identities I1D A 
and /Dg can compute the same key without any interaction 
in every time period ¿. 


to A. 


. Setup The challenger C runs the Setup and hands the resulting public parameters params to the 
adversary A. The initial master secret key mk" remains private, i. e., C does not forward the value mk 


. Phase 0 (Find) The adversary is allowed to make the following queries: 


- Extract(1D,i): The challenger C responds by running the algorithm MasterKeyUpdate of the key- 
evolving ID-NIKD scheme with input mkp until the master key of time period ¿, mk* is obtained. 
Then C runs the algorithm Extract with input (params, mk*, ID) and hands the resulting secret 
key Sípto A. 

- Reveal(I1Da,IDp,i): The challenger C responds by running algorithm MasterKeyUpdate of the 
key-evolving ID-NIKD scheme with input mkg until the master key of time period ¿, mk* is obtained. 
Then C runs the algorithm Extract with input (params, mk*, ID) to get a secret key S% p, and 
then SharedKey with input (params, Sp ,, 1Dp) to get a shared key Kg. Finally, C hands the 
value Kg to A. 

- Test(IDa,IDp,i): The challenger C computes K'*, y in the same way as for answering a Reveal 


query. Moreover, € chooses a random bit b pa (0,1). If b = 0, C hands K* y to A. Otherwise 
(b = 1), the challenger C hands a uniformly at random chosen element from SHK to A. 


— Only one Test query can be made. 
compromised. 
input is (1Dp, IDA, test). 


(IDp, IDA, ltest). 


The queries of 4 must satisfy the following restrictions: 
— All inputs ¿ of Reveal and Extract queries must satisfy ¿ > izest, 1.€., Only future keys may be 
— No Reveal query can be made on input (1D, 1D, itest), nor (1Dp, IDA, btest), 1f the Test query's 
- No Extract query can be made on input (1D a, itest), nor (IDp, itest), 1f the Test query”s input is 


. Phase 1 (Guess) The adversary outputs a value b' € (0,1) and wins if and only if b=0". 


Fig. 2. 


Now, to capture the security of a key-evolving ID-NIKD, we 
build on the security model used by Paterson and Srinivasan 
in [8], the main difference being the key evolution component 
in our model: In a scheme that is secure in the sense of 
Definition 6 below, an adversary cannot distinguish between a 
past shared key established between two users and a random 
element from SHK—even having the current secret keys of 
these users. Forward security is therewith achieved in the sense 
that shared keys will not be compromised, even if the private 
keys of users are compromised in the future. 

Definition 6 (forward-secure key-evolving ID-NIKD): 

A key-evolving non-interactive key distribution scheme 
is forward secure if the advantage of any probabilistic 
polynomial time adversary A in the game described in 
Figure 2 is negligible for all NV € N. Here the advantage of 
an adversary A is defined as 


Adv (k) = 


Pr(b =V1'] — 5 


It is not hard to see that a scheme that is forward-secure 
in the sense of Definition 6 meets security in the sense of 
Paterson and Srinivasan's indistinguishability of shared key 
(IND-SK) [8], as our model includes adversaries that play the 
game in the initial state (no key updates are made). 

Remark 1: Notice that the restrictions of the model in [8] 
hold, as only one Test query can be made, no Reveal query can 
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be made on the same input (1D 4,1Dp) as the Test query's, 
nor on input (1D, IDA), and no Extract query can be made 
on input /Da, nor I[Dpg, as the Test query has the initial 
(current) state as input. 


TV. REALIZING FORWARD-SECURE KEY-EVOLVING 
IDENTITY-BASED NON-INTERACTIVE KEY DISTRIBUTION 


In this section we describe a key-evolving ID-NIKD scheme 
in the random oracle model. Our construction is based on 
a proposal of Sakai et al. [9], incorporating key update 
algorithms as required in Definition 5. To so, in addition to a 
generator algorithm PairingGen we need a forward-secure 
pseudorandom bit generator as described in Section II. For the 
parameter m in Definition 1, we assume m > N, 1.e., that m 
1s not smaller than the total number of time periods NV and 
for the parameter b we assume 2? > q. Finally, we make use 
of random oracles 


H; : (0, de —+ G 
H: Gr — SHK=(Í0,1]” 
H3: [0,1 — (0,....q-1) 


The five comprising algorithms are as follows: 

+ Setup: On input the security parameter 1% and the 
total number of time periods N, PairingGen is used 
to obtain (G, Gry,e, q, P). In addition, Setup chooses 
an element so + (0,...,q — 1) uniformly at ran- 
dom, specifies a pseudorandom generator GEN  = 


(GEN.key, GEN.next, b, m) and matching random oracles 
H;,, Hz, Hz. Let ro € (0, 1)* be the seed generated by 
Gen.key and SHK = 0,1)”, where n > k. 

Setup outputs the public parameters params 
(G, Gr, e, XP, Po = so: P, H,, Ha, Haz, GEN. next, m, Dd, n) 
and the initial master secret key mk" = (sg, ro) 
MasterKeyUpdate: On input the previous master key 
mki=l1 = (s; 1,151), MasterKeyUpdate computes 
GEN.next(r,_1) = (Out;, St;) and outputs the current 
master secret key 


mk! = (H3(Out;)s¡-1, St) => (Sa Ti: 


KeyExtract: On input the current master secret key 
mk' = (s¡, r¿) and an identifier 7.D this algorithm outputs 
the secret key 


So = (s¿H UD), ri). 


+ KeyUpdate: On input a secret key TS = 
(s;1H1(1D),r;-1), this algorithm computes 


GEN.next(r;_1) = (Out;, St) and outputs the new 
secret key 


SharedKey: On input a current private key 5% p, and 
an identifier IDg € [0,1)*, where IDg 4 IDA, this 
algorithm outputs 


Kg = Hale(s¡H (IDA), H,(1Dg))). 


Making use of the bilinearity and symmetry of the map e, it is 
not difficult to verify that the above collection of algorithms 
indeed consitutes a correct key-evolving ID-NIKD scheme in 
the sense that users A and B will obtain identical keys when 
executing SharedKey with (S7p,,1D3) and (Sí p,,I1DA) 
respectively. 

Moreover, the above scheme turns out to be secure in the 
sense of Definition 6, provided that the underlying pseudoran- 
dom bit generator is forward-secure: 

Proposition 1: 1f GEN is a forward secure pseudorandom 
bit generator and the BDH assumption holds for the generator 
algorithm PairingGen, the above key-evolving ID-NIKD is 
forward-secure in the sense of Definition 6. 

A proof of this result will be given in the full version 
of this paper, and here we restrict to saying that the proof 
splits into two different cases: For an adversary not quering 
Extract or Reveal for time periods ¿ > “Test, the situation is 
similar as in [8], and a successful adversary can be used to 
attack the BDH problem for (G, Gr, e). For the case where an 
adversary queries Extract or Reveal for time periods ¿ > ¡Test, 
a successful attacker can be used to mount an attack against 
the forward security of GEN. 


V. CONCLUSION 


In this contribution we introduced the notion of key-evolving 
identity-based non-interactive key distribution which allows 
to capture an intuitive form of forward security for ID- 
NIKD schemes—in a spirit similar to forward-secure signature 
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schemes. As a concrete example of a scheme that fulfills the 
proposed security requirement, we gave a construction in the 
random oracle model, using pairings, based on a proposal of 
Sakai et al. and a forward-secure pseudorandom bit generator. 
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Abstract—En este trabajo se presenta un ataque criptoanalítico 
sobre el generador auto-shrinking, un generador de secuencia 
cifrante bien conocido por sus buenas propiedades criptográficas. 
Se propone un refinamiento de la técnica criptoanaltica de 
Guess-and-Determine, con supuestos definidos y elaborados a lo 
largo del propio proceso. Se presentan resultados numéricos que 
mejoran otros criptoanálisis planteados sobre dicho generador. 
Concretamente, se han logrado complejidades del orden de 
0(2%-22) para la cantidad de secuencia interceptada, O(L) para 
memoria consumida y O(2%*2) para tiempo de ejecución (siendo 
L la longitud del registro del generador). Se propone asimismo 
un hardware específico para un criptoanálisis de corte práctico. 


I. INTRODUCCIÓN 


Los sistemas de cifrado en flujo son los más rápidos dentro 
de los métodos de cifrado actuales, de ahí que se utilicen 
en numerosas aplicaciones prácticas como, por ejemplo, los 
algoritmos AS (en su doble versión A5/1 y A5/2) que se 
emplean en telefonía móvil GSM [5], el algoritmo E0 usado 
en especificaciones de Bluetooth [1] o el algoritmo RC4 
utilizado en Microsoft Word y Excel [11]. Un sistema de 
cifrado en flujo está compuesto por un algoritmo o generador 
de secuencia cifrante (conocido públicamente) y una clave de 
cifrado (conocida únicamente por los dos comunicantes). Para 
cifrar, el emisor realiza una operación OR-exclusiva bit a bit 
entre la secuencia cifrante y el texto claro (mensaje original), 
dando lugar al texto cifrado que es el que se va a enviar 
por el canal de información. Para descifrar, el receptor genera 
la misma secuencia cifrante que suma bit a bit con el texto 
cifrado recibido y recupera así el texto claro original. Muchos 
algoritmos de cifrado en flujo están basados en Registros 
de Desplazamiento con Realimentación Lineal (LFSRs) [4] 
cuyas secuencias de salida, las PN-secuencias, se combinan 
entre sí mediante algún procedimiento o función no lineal 
para producir una secuencia pseudoaleatoria de aplicación 
criptográfica ([2], [3], [8]). 

Los procedimientos de cifrado de flujo se utilizan para 
dar seguridad criptográfica a sistemas de comunicaciones con 
requerimientos de velocidad y sincronismo. Uno de estos 
ejemplos de cifrador en flujo es el generador auto-shrinking. 
La Unión Europea, a través del Proyecto Stork [12], propuso 
a la comunidad científica internacional romper este generador 
mediante alguna técnica criptoanalítica que mejorase el ataque 
tipo TMTO (Time Memory Trade Off). En este trabajo, se 
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presenta un técnica de criptoanálisis efectiva aplicada sobre 
dicho generador, para distintas longitudes L de su registro 
de desplazamiento con L < 120. Concretamente, se ha de- 
sarrollado un método basado en trabajos anteriores realizados 
sobre el generador auto-shrinking, en particular [14], logrando 
mejorar en varios órdenes de magnitud lo alcanzado en di- 
cho trabajo. Esta mejora permite asegurar que el generador 
puede romperse en tiempo real. La complejidad de memoria 
necesaria es muy pequeña, concretamente de O(L?), mientras 
que la complejidad de secuencia interceptada (datos) tiene un 
orden menor que O(2%-22), Por otra parte, la complejidad en 
tiempo que hemos logrado es menor que O(2%-*2). De hecho, 
haber logrado disminuir este valor, en comparación con el de 
otros autores, es lo que hace que nuestro criptoanálisis pueda 
realizarse en tiempo real con un hardware dedicado. 


TI. EL GENERADOR AUTO-SHRINKING 


El generador auto-shrinking fue diseñado por Meier y 
Staffelbach [7] para su uso en aplicaciones criptográficas. Este 
generador es de fácil implementación y consiste en un único 
LFSR de L£ etapas y polinomio de realimentación primitivo. 
Este registro genera una única secuencia pseudoaleatoria, 
(sn), la cual se decima de forma irregular dando origen 
a la secuencia auto-shrunken, [z,,), o secuencia de salida 
del generador. La regla de decimación es extremadamente 
simple; se consideran pares (s2;,82;+1) (4 = 0,1,2,...) de 
bits consecutivos de (s,,) tales que: 

1) Si s); = 1, entonces 2; = Soj41- 

2) Si s2; = 0, entonces sa;+1 se rechaza. 

Es decir, si el primer bit del par considerado es un l, 
entonces el segundo bit se inserta en la secuencia de salida. 
Por el contrario, si el primer bit del par considerado es un 
0, entonces el segundo bit se rechaza. De esta manera, se 
van eliminando determinados bits de la secuencia (s,,) y los 
que quedan constituyen la secuencia (2, o secuencia auto- 
shrunken. La clave de este generador es el estado inicial del 
LFSR. De acuerdo con [7], el periodo, la complejidad lineal 
y las propiedades estadísticas de la secuencia [z,,) son muy 
adecuados para su aplicación en criptografía. 

La secuencia [s,,), generada por el LFSR, puede consid- 
erarse formada por dos secuencias diferentes [c,) y 4(b,) 


TABLE I 
h(x) PARA DIFERENTES POLINOMIOS P¿(1) DE GRADO L 


L Pou) h(x) 
36 a y 2541 6,13,24 
40 x%0 4 g38 y y22 4 20 41 11,29, 30 
52 a52 4 949 41 2,25, 28 
100 al00 4 q37 41 19, 32, 69 
278 2278 4 273 4 1 3,137,142 
455 245 4 g3 y 230 7 gl16 41 3,4,62,118, 
171,176, 228, 


229, 287,343, 401 


que responden a los bits de subíndices pares e impares, 
respectivamente, de la secuencia (s,,). Es decir: 


S2í vVi>0 
sai+1 W1>0. 


(1) 
(2) 
A su vez, estas dos secuencias corresponden a la misma 
PN-secuencia (s, | generada por el LFSR pero desplazadas 
entre sí una distancia de 2/71 bits. La existencia de dicho 


desplazamiento permite expresar una secuencia en función de 
la otra [14]. Así vemos que: 


L-1 
di = > h; Ci4j) 
j=0 


donde los hz son los coeficientes de h(x) un polinomio de 
grado L— 1 y coeficientes binarios definido por: 


C; 


bi 


(3) 


h(a) = 22%” mod Pa), (4) 


siendo P.(x) el polinomio característico del LFSR. 

De esta forma expresamos los bits impares de la secuencia 
[s,) que son los b; en función de los bits pares que son 
los c;+;. Nótese que calcular el polinomio h(x) para valores 
de L elevados no es trivial. De hecho, en este trabajo se ha 
desarrollado un programa ad-hoc basado en propiedades de la 
aritmética modular. En la Tabla I se presentan los resultados 
obtenidos para distintos polinomios característicos de grado 
L. La representación del polinomio A(x), por ejemplo en el 
caso 6,13, 24, corresponde a h(x) =xé +28 4 22. 


III. ATAQUE PROPUESTO 


Este método criptoanalítico se encuadra dentro de las 
técnicas que poseen una componente estadística y una al- 
gebraica. Como vimos anteriormente dentro de la secuencia 
[sn ) podemos distinguir otras 2 secuencias [c.) y (bp). 
Romper el generador significa hallar la condición inicial para 
las secuencias (c,,) y [b, | o un punto de las mismas a partir 
del cual es posible continuar generando la secuencia [z,,). 


A. Idea general 


La idea general del ataque se concreta en los siguientes 
puntos: a partir del conocimiento de N bits de la secuencia 
[zn) (bits interceptados) y de la suposición de 1 bits de 
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la secuencia [c,,), en concreto (co, C1,...,c¡-1), se plantea 
un sistema de ecuaciones lineales vía la ecuación (3) para 
determinar: 


1) Los restantes bits de [c,,), notados (c,,C1+1,...,CL-1). 
2) Los correspondientes de la secuencia (b,), notados 
(bo,b1,...,bL-1). 

Una vez conocidos los L primeros bits de cada secuencia se 
genera una cierta cantidad de secuencia auto-shrunken y se 
compara con los bits de secuencia interceptada. Si el resultado 
coincide, entonces el generador está roto. Si el resultado no 
coincide, nos desplazamos un bit sobre la secuencia inter- 
ceptada y repetimos el proceso. Si no encontramos solución 
tras los sucesivos desplazamientos sobre los bits interceptados, 
entonces tomamos una nueva suposición de / bits de la 
secuencia [c,,) y repetimos el proceso. Veamos un ejemplo 
sencillo. 

Ejemplo 1: Sea un LFSR con polinomio característico 
P.(1) = 1% + a? + 1. Las secuencias generadas para una 
condición inicial del registro son: 


(fenj =4f1,0,1,1,1,0,1,1,0,0,0,1,1,1,1,1,0,0,1,1,...) 
(b, + =10,0,1,1,0,1,0,0,1,0,0,0,0,1,0,1,0,1,1,1,...) 
£zn) =(0,1,1,0,0,0,0,0,1,0,1,1,1,...). 

Para l = 3, conocemos N = 5 bits interceptados que 


comienzan en zp y consideramos, por ejemplo, la suposición 
(co, c1,c2) = (1,0, 1). Con estos datos planteamos el sistema 
de ecuaciones y si es posible lo resolvemos. En efecto, los 
bits que nos restan son (c3,c4) y (bo,b1,b2,b3,b4). Al ser 
Co = 1, sabemos que by = zy = 0. Como cy = 0, entones bj 
se desconoce. Hay que tener presente que sólo los bits c; = 1 
introducen ecuaciones en el sistema. En este ejemplo estamos 
considerando una suposici con q = 1 cero. A continuación, 
como cz = 1, entonces b2 = 2, = 1. A partir de la relación de 
recurrencia lineal del LFSR, el polinomio h(x) = 1?+a* y la 
ecuación (3), planteamos el siguiente sistema de ecuaciones. 


bo = C2+C3 

bi = (3 + Ca 

ba = Cp+C3+CaA 

b3 = Co+Cci+C3+Ca4 

ba Co+C1+C2+C3+Ca. 


Dado que a partir de la suposición de partida, se han de- 
spejado (bo,b2), podemos resolver el sistema de ecuaciones 
anterior obteniendo los valores de (c3,c4) y (b1,b3,b4). Una 
vez conocidas las condiciones iniciales: (cp, C1,C2,C3,C4) = 
(1,0,1,1,1) y (bo,b1,b2,b3,b4) = (0,0,1,1,0), se genera 
una porción de secuencia cifrante [Zresu + = (0, 1,1,0,0,...), 
se comparan los bits generados con los bits interceptados y si 
coinciden, como ocurre en este ejemplo, entonces podemos 
decir que el sistema está roto. 


B. Algoritmo criptoanalítico 


Introducimos primeramente alguna notación adicional: 


1 es la k-ésima suposición para los primeros / bits 
de la secuencia [c,,p con (1 < k < Qrear), siendo Qrea! el 
número total de suposiciones que van a analizarse. 

Can representa la cantidad óptima de bits que se consideran 
para una comparación válida entre bits interceptados y bits 
generados. 

A continuación vemos el esquema del algoritmo progra- 
mado: 

Input: Polinomio P,(x) de grado L, l, segmento de N 
bits interceptados, puntero z al primer bit interceptado zo, 
polinomio h(x) y bloque de suposiciones (CyJy * con (1 < 
k < Qreal): 

Inicializar: l  L/2, Can =2,5x L. 

For k = 1: |(Qrea¡| para cada suposición ero 

While puntero z < N 

Paso 1: Plantear el sistema de ecuaciones lineales. 
Paso 2: Resolver el sistema ecuaciones dejando a lo 
sumo un número n (acotado) de bits sin resolver. 
Paso 3: Determinar los valores de (cp, C1,...,CL-1) 
y (bo,b1,...,bL-1). Generar Can bits de secuencia 
Paso 4: Comparar bits interceptados con bits gener- 
ados. Si son iguales break. 
Paso 5: z=2+1. 

end 

k=k+l se toma una nueva suposición, z =0 
end 

Output: (co,c1,...,CL-1) y (do,b1,...,b1-1) con los que 
es posible continuar generando secuencia auto-shrunken. 

Con respecto a este ataque, si bien la idea es sencilla y 
por tanto efectiva, hay ciertas observaciones que merecen ser 
tenidas en cuenta. 

Observación 1: Cuanto mayor sea el número de ceros en 
cada suposición, menor la cantidad de ecuaciones que podrán 
considerarse en el sistema de ecuaciones y, por tanto, mayor 
la cantidad de bits no resueltos. 

Observación 2: No todas las suposiciones son aptas para 
la resolución del sistema, por lo que hay que seleccionarlas 
adecuadamente. Esta selección de suposiciones es lo que hace 
de nuestro criptoanálisis un ataque más efectivo que el que 
utiliza la técnica de Guess and Determine [14]. 

Observación 3: Definir el bloque de suposiciones óptimas 
para el generador en cuestión implica no sólo que sea el bloque 
con la menor cantidad de suposiciones posibles, sino también 
que sea aquél que logra resolver la mayor cantidad de bits de 
(c0,C1,...,CL—1). De este modo se logra un equilibrio entre 
complejidad en tiempo y complejidad de datos interceptados. 


C. Cálculo del Bloque de Suposiciones 


Una forma de abordar la selección de suposiciones es 
tal y como se realiza en [14] y [9], es decir considerando 
una cantidad muy elevada de ellas. En este trabajo por el 
contrario el número de suposiciones es mucho menor puesto 
que elegimos sólo las suposiciones óptimas, esto es aquéllas 
que sean capaces de resolver la mayor cantidad de bits en 
(co, C1, ... ,CL-1). 
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Por otro lado, para una PN-secuencia binaria, vemos que 
la distancia entre bloques no superpuestos de 0 con 
q ceros dependerá del grado L del polinomio característico 
del generador. Esta distancia es la que nos dirá cuántos 
bits de secuencia interceptada son necesarios para romper el 
criptosistema con una alta probabilidad de éxito Perito. 

Es importante notar que, en ocasiones, parte de los bits 


ecuaciones que se plantea no permite la resolución de todas 
las incógnitas. 

La resolución óptima del sistema de ecuaciones es sensible 
a las ecuaciones que lo conforman. Si en la suposión 150 
hay un cero en c;, entonces no se conoce el correspondiente 
valor de hb; y esa ecuación no forma parte del sistema. La 
idea de la optimización es descartar suposiciones que posean 
un cero que impida contar con alguna ecuación considerada 
importante, dado que a través de ella es posible resolver una 
mayor cantidad de bits. 

Concluímos que no todas las ecuaciones inciden por igual 
en la resolución del sistema. La manera de limpiar el total de 
posibles suposiciones LES con un número q de ceros en 
sus bits es seleccionar de entre ellas, sólo las que posean un 
1 en la ecuación que interesa. 


IV. RESULTADOS NUMÉRICOS 


El tiempo de procesamiento se computa considerando el 
número de suposiciones que se utilizan en el ataque y la canti- 
dad de bits que componen el bloque de secuencia interceptada. 
Se tendría así el número total de intentos para romper el 
criptosistema, es decir el orden de complejidad en tiempo. Hay 
que tener presente que sólo son necesarios L bits de secuencia 
interceptada para plantear el sistema de ecuaciones y romper el 
generador. El problema es que no sería realista considerar que 
el sistema rompe el generador precisamente en el primer bit 
de la secuencia interceptada disponible. Por ello se toman N 
bits interceptados y nos desplazamos dentro del bloque hasta 
encontrar la solución correcta. Esto es, el estado del LFSR 
que nos permite seguir generando secuencia cifrante (2,,). 


A. Comparación con otros Criptoanálisis 


A partir de los resultados numéricos obtenidos, se han 
construido las siguientes Tablas comparativas. En la Tabla 
II aparecen representados los resultados de este trabajo para 
distintos valores de L y de los parámetros: Q...,, cantidad de 
suposiciones, N cantidad en bits de secuencia interceptada, 
Bnr número de bits sin resolver, Cy complejidad en tiempo, 
Cu complejidad en memoria, Cp complejidad de datos 
interceptados y Pexio porcentaje de éxitos obtenidos. Para 
cada valor de L se han considerado del orden de 10 polinomios 
característicos distintos, promediándose los resultados. 

En la Tabla III se comparan para un £ fijo los parámetros 
utilizados por varios autores en cuanto a longitud / de la su- 
posición, número de suposiciones (Q-ea1, longitud de secuencia 
interceptada N y cantidad de ceros q en cada suposición. Se 
aprecia que en [14] la cantidad de ceros en cada suposición es 


TABLE HU 
L VERSUS DIFERENTES ÓRDENES DE MAGNITUD 


L Orcal N Bnr Cp<o(2rL) Cy <O(%) Cp<O(QUBL) Perito 
36 1736 500 2 O(211 + 29) 1? 29 87% 
40 2736 950 3 O(211 y 210) L? 910 100% 
52 12376 5500 4 0(24 + 212) E? 912 85% 
100 462411533 2 12-13 0(228 y 221) L? gal 97% 
120 293 225 11 O(2% y 225) L? 225 =O(20-2*L) 97% 


mayor y, por tanto, la cantidad de bits no resueltos aumentará 
lo que traerá consigo una mayor complejidad en tiempo. 

En la Tabla IV se comparan las complejidades Cr, Cu y 
Cp para los diferentes autores. La diferencia principal del pre- 
sente trabajo con el expuesto en [14] es que Zhang ef al. tratan 
de resolver todas las ecuaciones posibles, con el inconveniente 
de que quedarían muchos bits sin determinar. En cambio 
en nuestro trabajo, sólo resolvemos aquellas ecuaciones que 
minimizan la cantidad de bits no resueltos. De este modo 
podemos calcular que la cota máxima para complejidad en 
tiempo es O(20:6L), mientras que para [14] esta cota asciende 
a O(22). En este punto hay que señalar también que hay 
polinomios P.(x) que tienen mejores prestaciones a la hora 
de resolver el sistema de ecuaciones, dejando menor cantidad 
de coeficientes c; sin resolver. 


V. IMPLEMENTACIÓN HARDWARE 


Esta sección no pretende ser más que un esbozo de una 
implementación hardware del critpoanálisis desarrollado en 
las secciones anteriores sobre el generador auto-shrinking. Se 
pretende dejar planteada una arquitectura de cara a un desar- 
rollo futuro. Los programas se han escrito en Matlab logrando 
todos los objetivos perseguidos. Sin embargo, cabe destacar 
que para un criptoanálisis con tiempos de procesamiento bajos, 
además del método propuesto y de los programas realizados, 
hay que llevar a cabo una programación óptima con los 
medios que hoy por hoy la tecnología permite y nuestros 
conocimientos también. El propósito fundamental de imple- 
mentar el critptoanálisis mediante programación en paralelo 
es minimizar el tiempo que se tarda en recuperar la condición 
inicial del registro. Desarrollar así este criptoanálisis, require 
una programación adecuada y un medio físico para imple- 
mentarla. La programación adecuada implica una orientación 
al bit, eliminando tiempos espúreos y memoria innecesaria. 
Todo programa corriendo en entornos poco controlables, como 
puede ser un sistema operativo, ya no sería óptimo. La 
solución, que logra aunar todas estas condiciones, es lo que 
se denomina Lógica Programable o más comúnmente FPGA, 
Fast Programmable Gate Array. Esta lógica programable está 
orientada al bit, no posee un sistema operativo y todos sus 
componentes trabajan a velocidades próximas al reloj al que 
la lógica está conectada. Siendo conservadores, estos relojes 
están en el rango de 40-100 Mhz y vienen instalados en 
distintas placas de desarrollo conjuntamente con las FPGAs 
[13]. La programación en paralelo es propia de este tipo de 
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lógica y por tanto sería nuestra elección a la hora de un desar- 
rollo con propósitos criptoanalíticos. Los componentes lógicos 
programables de una FPGA pueden tener la funcionalidad 
de puertas lógicas básicas como AND, OR, XOR, NOT o 
incluso funciones combinacionales más complejas, tales como 
decodificadores o funciones matemáticas simples. Consisten 
en un arreglo de bloques lógicos programables (CLB: Config- 
urable Logic Block) y canales de ruteo también programables. 
La implementación de un LFSR mediante FPGAs es muy 
sencilla y puede llevarse a cabo utilizando configuraciones ya 
disponibles en los chips FPGA. Se aprecia que implementar un 
generador Shrinking o un generador auto-shrinking en este tipo 
de hardware no requiere de gran esfuerzo, ya que el mismo 
entorno de la FPGA está diseñado para admitir este tipo de 
generadores. 

Por otra parte, la frecuencia de salida de los bits de 
secuencia cifrante sería sumamente elevada y estaría dada por 
el ocilador del reloj que se conecta a los flip-flops. Para tener 
una noción de velocidades, este reloj estaría oscilando a unos 
40-100 Mhz en placas de desarrollo de FPGAs de muy bajo 
coste, siendo más veloces en placas menos económicas. 

Hasta el momento hemos hablado del criptoanálisis de este 
generador, pero como ya dijimos los tiempos computacionales 
están en un orden de O(2%92) y este valor se mantiene 
para todo L. Para establecer sólo magnitudes de tiempos de 
computación se realizó una comparación sobre procesos muy 
simples, corriendo en diferentes lenguajes de programación 
como son el Matlab y el Labview y se extrapoló el tiempo que 
tardaría el proceso en correr sobre una placa FPGA (NI-RIO- 
EVAL-101National Semiconductors) [10]. Para realizar esta 
extrapolación se compararon muchos procesos corriendo en 
Labview y luego programados en la lógica FPGA. La relación 
entre tiempos dio como resultado que la placa FPGA tarda 
entre 100 y 500 veces menos que la programación en Labview. 
Debemos decir que Labview es un herramienta de análisis 
orientada a señales digitales, manejo de bits, puertas lógicas, 
medición de tiempos precisos, estadística y otras funciones. Al 
estar orientada al bit, mejora la prestación que Matlab puede 
otorgar para la función que precisamos. Es un lenguaje que se 
puede traducir a la lógica programable con relativa facilidad 
y, por tanto, disminuye el tiempo de la puesta en marcha de 
cualquier programa para que corra en una placa de desarrollo 
FPGA. Veamos ahora la comparación en cuanto a tiempos de 
procesamiento para un proceso particular como sería: generar 
el conjunto de suposiciones que hemos desarrollado para 


TABLE III 
COMPARACIÓN DE PARÁMETROS POR AUTOR PARA L = 40 
L=40 Qreal N q 
Mihaljevic, 1 =20  2%7!= 1048576 108 
Pazo Robles, l = 20 2736 700 — 800 2 
Zhang, l = 25 222 O(28) 9-10 
TABLE IV 
COMPLEJIDADES POR AUTOR 
Autor Cr Cu Cp 
Mihaljevic O(20-5*L) O(L) O(20-5*L) 
Pazo Robles  O(20**L) - O(20:é*15 O(1%)  <oO(20-25:L) 
Zhang o(20-7*L) - O(2£) O(L2) O(29:2*L) 


nuestro criptoanalálisis. Comparamos Matlab, Labview y la 
extrapolación para la placa FPGA. Para generar una suposición 
en cada entorno programado vemos lo siguiente: 


. Tiempos en Matlab: El proceso de cada suposición tarda 
15 mseg. 
Tiempos en Labview: El proceso de cada suposición tarda 
0,5 mseg. 
Tiempos previstos en la placa FPGA: El proceso de cada 


suposición tarda 0,001 mseg, es decir 1 seg. 


Pasar de trabajar en Matlab a Labview significó una dismin- 
ución de 30 veces en el tiempo de generar suposiciones. Por 
otro lado pasar de Labview a FPGAs creemos que significará 
al menos una disminución de entre 100 y 500 veces el tiempo 
previsto en Labview. Esta relación sale de la experiencia de 
otros ingenieros que ya han hecho este tránsito. Por supuesto, 
dependerá de la capacidad de programar en paralelo el proceso 
concreto que se quiere correr, pero ronda esas magnitudes. Ve- 
mos en la Tabla V la comparación entre tiempos de programas 
para generar suposiciones para distintos valores de L. Todos 
los programas pueden realizarse bajo una programación en 
paralelo, lo que supondría bajar los tiempos del modo que se 
ha planteado. Creemos que dará resultados muy positivos y 
que el generador auto-shrinking a estas alturas está roto en 
tiempo real para un £ < 100. 


VI. CONCLUSIONES 


En este trabajo se ha logrado: 


1) Un criptoanálisis del generador auto-shriking con 
órdenes de complejidad que superan los alcanzados por 
otros autores hasta la fecha [9], [14]. 
Obtener resultados de complejidad en tiempo menores 
que O(2%*L), de una complejidad de datos menor que 
O(2%:25L) y una complejidad en memoria de O(L2). 
3) La pre-computación es baja en tiempo. Debido a la dis- 
minución de los órdenes de magnitud, específicamente 
la complejidad en tiempo, este criptoanálisis propuesto 
es concebible en tiempos computacionales aceptables, a 
diferencia de los propuestos por otros autores. 


2) 
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TABLE V 
TIEMPOS PARA GENERAR SUPOSICIONES SEGÚN L Y ENTORNO DE 


PROGRAMACIÓN 
L Ns Matlab  Labview FPGA 
36 1736 26 seg 0,86 seg 1,736 seg 
40 2736 41 seg 1, 4 seg 2,736 seg 
52 12376 186 seg 6,2 seg 12,375 mseg 
100 462411533 80 días 2,5 días 7—8 min 


4) Exponer claramente las mejoras logradas con respecto a 
otros autores, profundizando en el estudio y logrando 
una originalidad en el criptoanálisis basada en una 
selección fina de cada una de las suposiciones que 
intervienen en el proceso. 

Cumplir el objetivo planteado en el proyecto Stork [12] 
de romper el generador auto-shrinking con compleji- 
dades menores a las logradas mediante la técnica de 
Time Memory Trade Off. 

Dejar planteado, para un trabajo futuro, un esquema 
razonable y factible de desarrollo en hardware, que 
permita en tiempos computacionales aceptables, romper 
el generador auto-shrinking. 


5) 


6) 
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Resumen—El algoritmo Rho de Pollard es el mejor algoritmo 
conocido para resolver el problema del logaritmo discreto en 
algunos grupos como el grupo de puntos de una curva elíptica o 
la variedad jacobiana de una curva hiperelíptica. El algoritmo se 
basa en hallar una colisión dentro de una secuencia pseudoaleato- 
ria que una vez encontrada permite calcular la solución del 
problema. Exiten diversos métodos para hallar esta colisión que 
pueden clasificarse según si su uso de memoria es negligible o no. 
En este artículo presentamos una propuesta para paralelizar la 
búsqueda de colisiones con uso de memoria negligible que ofrece 
un speedup proporcional al número de procesadores disponibles. 


I. INTRODUCCIÓN 


La seguridad de las cifras de clave pública [13] se basa en 
la supuesta inexistencia de algoritmos eficientes para resolver 
determinados problemas matemáticos tales como el problema 
de la factorización entera (cifra RSA [8]) o el problema del 
logaritmo discreto (cifra ElGamal [2]). A la hora de fijar los 
parámetros de un criptosistema basado en alguno de estos 
problemas es necesario tener en cuenta el coste del mejor 
algoritmo que lo resuelve y escoger así unos parámetros lo 
bastante grandes para garantizar la seguridad pero sin sobred- 
imensionar el sistema ya que esto penalizaría el rendimiento. 

Sea G un grupo multiplicativo de orden p y sea g un 
generador de G. Dado h € G, el problema del logaritmo 
discreto consiste en encontrar un entero m tal que g” = h 
(esta expresión puede ser reescrita como m = log, h). Cuando 
el orden del grupo G tiene un factor primo grande, existen 
grupos donde el mejor algoritmo conocido para su resolución 
tiene un coste no polinomial, haciéndolos adecuados para su 
uso en criptografía. 

Por ejemplo, cuando G es el subgrupo multiplicativo 
de un cuerpo de Galois IF?, el algoritmo index-calculus 
calcula un logaritmo discreto con un coste subexponen- 
cial O(eViesaloslosg) Si q es primo, el algoritmo number 


field sieve reduce este coste a O(e1923(08 4) 3 (log log 4)% 
véase [10]. 

Para otros grupos, tales como el grupo de puntos de 
una curva elíptica o la variedad jacobiana de una curva 
hiperelíptica, el mejor algoritmo conocido es el algoritmo 
Rho de Pollard [7] cuyo coste (exponencial respecto a la 
longitud de p) es O(./p), donde p es el cardinal del grupo 
G. Su coste exponencial implica que su ejecución termina en 
un tiempo aceptable solamente cuando p tiene una longitud 
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reducida. Para resolver instancias con longitudes mayores de p 
será necesaria la utilización de varios procesadores ejecutando 
una versión paralelizada del algoritmo. 

La calidad de una paralelización se mide mediante el 
parámetro speedup que se define como el cociente entre el 
tiempo de ejecución de un algoritmo y el tiempo de ejecución 
de su versión paralelizada. El valor óptimo de este parámetro 
se obtiene cuando corresponde con el número de procesadores 
de que disponemos. Alcanzar el valor óptimo significa que si 
disponemos de M procesadores estamos dividiendo el tiempo 
de ejecución por M. Este valor óptimo no suele alcanzarse 
ya que un algoritmo paralelizado pierde rendimiento a causa 
de la gestión de procesos y por el intercambio de mensajes e 
información que hay entre ellos. 

En este artículo presentamos una forma de paralelizar el 
algoritmo Rho de Pollard mediante la cual se consigue un 
speedup proporcional a M y cuyos requisitos de memoria son 
negligibles. 


TI. 


El algoritmo Rho de Pollard resuelve el problema del loga- 
ritmo discreto sobre un grupo G de orden p (dados g,h € G, 
calcula log, h) a partir de dos pares distintos (a;,b;), (aj, b;) 
de enteros módulo p que satisfacen 


EL ALGORITMO RHO DE POLLARD 


go po: NN go pb. 
Operando la expresión anterior se obtiene, 


pei=bs == gaia 
lo cual permite calcular log, h como, 


(1) 


El algoritmo Rho de Pollard utiliza una función f : G > 
G tal que dada una tripleta (x;,a;,b,) que satisface 1, = 
g hb: € G, es fácil calcular otra tripleta distinta (x;, ay, b;) 
tal que 2; = f(2;) y 1, = g4hbi, La función f ha de tener 
un comportamiento pseudoaleatorio. Pollard sugiere dividir los 
elementos de G en tres grupos distintos 71, Ta y T3 y el uso 
de la siguiente función 


log, h= (a; == a) (0; == bj) (mód p). 


gí, sixeT, 
(Mer a, si E To, 
hz, si ET. 


En [11] se estudia el uso de otro tipo de funciones. 
De este modo se puede definir una función F' que retorna 
(us, 05,0,) = F(£;, 0:,0;,), con 2; = f(z;), de la siguiente 
manera, 


(gu;, as +1, b;), si 2, ET, 
Pla, 05, bi) = (ee 245, 2b;), si t¡ € Ta, 
(hz;, Qi, di + 1), si 2, € T3, 


siendo las operaciones sobre a; y b; módulo p. 

Comenzando desde una tripleta cualquiera (xp, ao, bo), 
se puede construir la secuencia ¿(x;,a;,b;))i>0 donde 
(x,,0,b;) = Flx;-1,05-1,0;-1), para ¿ > 1. Dado que el 
grupo G es finito, existe un índice £ para el cual 1, = 2¿_; 
para algún s > O. Entonces 2, = 2;_s para todo 1 > t con 
lo cual la secuencia entra en un ciclo. A partir de la paradoja 
del aniversario se demuestra que el camino generado antes 
de que se produzca la primera colisión (valor del índice 1) 
tendrá una longitud esperada de ,/mp/2. El algoritmo Rho 
de Pollard encuentra una de estas colisiones (dos tripletas 
distintas (x;,a;,b,), (1,,a;,b,) con a; = 25) y resuelve el 
logaritmo discreto aplicando la fórmula (1). Dicha colisión 
puede buscarse mediante el algoritmo de Floyd (tal como se 
propone en [7]) o utilizando el algoritmo de Brent [1]. 


IIT-A. Algoritmo de Floyd para búsqueda de colisiones 


Para encontrar una de estas colisiones puede usarse el 
algoritmo de búsqueda de ciclos de Floyd (también conocido 
como el algoritmo de “la tortuga y la liebre”). Este algoritmo 
utiliza dos tripletas que avanzan a lo largo de una misma 
secuencia que comienza en una tripleta cualquiera (20, ao, bp). 
Una de ellas, la tortuga, avanza un paso en cada iteración 
mientras que la otra, la liebre, avanza dos pasos por iteración. 
Una vez las dos tripletas han entrado en el ciclo, hay un 
momento en el que la liebre alcanza a la tortuga, hallándose 
de este modo una colisión. 


Algorithm 1 Algoritmo de Floyd 


Input: Una tripleta (xp, ag, bo) 
Output: Dos tripletas distintas (27, ar, by), (1,,a1,bL) 


con TT =XTL 
1 (xp, ay, by) i= (Zo, 40, do); 
2 (2,,a1,b,) := F(xr, ar, br); 


3 while 1, 4 xy do 

4 (27, ar, br) i= Fer, ar, br); 

5 (x,,aL,bL) i= F(F(x1,aL,bL)); 
6 end 

7 return (2, aq, br), (x,,aL,bL); 


Este algoritmo solamente necesita memoria para almacenar 
dos tripletas. El número de operaciones a realizar sobre el 
grupo para encontrar una colisión es aproximadamente 3,/p. 


II-B. Algoritmo de Brent para búsqueda de colisiones 


El algoritmo de Brent [1] permite encontrar colisiones 
mediante una técnica distinta también basada en el uso de 
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dos tripletas llamadas tortuga y liebre. En este algoritmo 
la liebre avanza un paso en cada iteración mientras que la 
tortuga permanece quieta. La tortuga toma el valor de la libre 
una vez esta última ha realizado 2? saltos desde la última 
actualización de la tortuga. El índice ¿ toma un valor inicial 
de 1 y es incrementado en una unidad cada vez que la tortuga 
es actualizada. 


Algorithm 2 Algoritmo de Brent 


Input: Una tripleta (xo, ao, bo) 
Output: Dos tripletas distintas (1-7, a7,by), (2,,aL,bL) 


con TT =TL 
1 (27,ap,by) := (20, ao, do); 
2 (x,,aL,bL) i= F(zr, ar, br); 


3 Longitud := Pasos := 1; 
4 while 1, 4 xy do 


5 if Pasos=Longitud then 

6 (xp, ay, by) i= (x,,aL,bL); 
7 Longitud := 2 x Longitud; 
8 Pasos := 0; 

9 end 

10 (x,,aL,bL) i= F(x,,aL,bL); 
1 Pasos := Pasos + 1; 

12 end 


13 return (up, ar, by), (14,09,0p); 


Igual que el algoritmo de Floyd, este algoritmo tiene un 
coste espacial negligible. En [1] se afirma que su utilización 
incrementa la velocidad del algoritmo de Pollard alrededor de 
un 24%. 


II-C. Búsqueda de colisiones con uso de memoria 


Tanto el algoritmo de Floyd como el de Brent encuentran 
una colisión sin apenas utilizar memoria con aproximada- 
mente 3,/p Operaciones sobre el grupo. Existen propuestas 
que reducen el tiempo necesario para encontrar la colisión a 
expensas de aumentar los requisitos de uso de memoria. Por 
ejemplo, en [9] se da una propuesta que reduce el número de 
operaciones a realizar sobre el grupo a y/p (1 + =») si se 
dispone de memoria para almacenar M tripletas. Otro ejemplo 
es la propuesta de [4] donde se usa una pila de memoria de 


tamaño O(log /p). 
III. PARALELIZACIÓN DEL ALGORITMO RHO DE 
POLLARD 


El algoritmo Rho de Pollard ejecutado sobre un grupo G 
de orden p tiene un coste O(,/p). Por tanto, a medida que 
p aumenta de tamaño, el tiempo necesario para ejecutarlo 
aumenta exponencialmente hasta convertirse en un problema 
intratable. El rango tamaños de p para los cuales el algoritmo 
es tratable puede aumentarse cuando disponemos de diversos 
procesadores mediante la ejecución de una versión paralelizada 
del algoritmo. 


HITA. Paralelización directa 


Cuando se dispone de varios procesadores, el algoritmo Rho 
de Pollard puede paralelizarse de forma trivial haciendo que 
cada procesador ejecute el algoritmo de forma independiente 
partiendo de una tripleta inicial distinta. El algoritmo par- 
alelizado se detiene cuando cualquiera de los procesadores 
halla la primera colisión. Si disponemos de M procesadores 
y buscamos la colisión mediante el algoritmo de Floyd o el 
de Brent (lo cual nos permite un uso negligible de memoria), 
el número esperado de operaciones sobre el grupo realizadas 
por cada procesador en el momento de encontrarse la primera 
colisión es de 3vVH con lo cual la propuesta proporciona 
un speedup que es solamente un factor de YM lo cual 
resulta muy poco eficiente (por ejemplo, para reducir el tiempo 
de cálculo a una cuarta parte es necesario el uso de 16 
procesadores). 


HIFB. Búsqueda paralela de colisiones mediante tripletas 
distinguidas 


En [6] se propone una versión paralela de búsqueda de 
colisiones que permite paralelizar el algoritmo Rho de Pollard 
con un speedup proporcional a M cuando se dispone de 
M procesadores y de una zona de memoria para almacenar 
tripletas. 

En esta propuesta, cada procesador escoge una tripleta al 
azar (xo, do, dp) desde la cual construye un camino de tripletas 
(x,,0,b) = Flx;¡_-1,05-1,0;-1), + > 0, hasta encontrar un 
valor 1¿ que satisface una determinada condición de fácil 
comprobación. Esta tripleta distinguida, (24, 44, b4) es enviada 
a un procesador encargado de recoger y almacenar las tripletas 
distinguidas que le irán mandando los otros procesadores. El 
procesador que halló la tripleta distinguida, después de man- 
darla, generará una nueva tripleta inicial al azar y repetirá el 
mismo proceso. El algoritmo termina cuando el procesador 
encargado de recoger las tripletas distinguidas recibe una 
tripleta (x¿,a4,b4) cuyo valor x¿ coincide con el de otra 
tripleta distinta almacenada previamente. En este momento ya 
se ha hallado una colisión y el algoritmo termina. 

La propiedad que distingue algunos elementos del grupo G 
ha de escogerse de manera que la proporción de elementos que 
la satisfacen sea 6. Dado 0, el número de operaciones sobre 
el grupo realizadas por cada procesador antes de hallarse la 
primera colisión (coste temporal) es 


1 
M 


(2) 


Puede ocurrir que la secuencia calculada por alguno de los 
procesadores entre en un ciclo sin puntos distinguidos. Una 
forma de recuperarse de esta situación consiste en establecer 
una longitud de camino máxima (en [6] se recomienda 20/0) 
que si es alcanzada por algún camino, éste será abandonado 
y se iniciará el recorrido de otro camino desde una tripleta 
aleatoria generada al azar. 

La fórmula 2 supone que hay suficiente memoria para 
almacenar todas las tripletas enviadas al procesador que las 


81 


almacena. Como tenemos M procesadores trabajando en par- 
alelo y cada uno de ellos envía una proporción 0 de tripletas 
a la lista, el número de tripletas que serán almacenadas es 


Tp 
—+M. 
9) ) ++ 


El parámetro 0 ajusta el compromiso entre los costes tempo- 
ral y espacial. Un valor grande de 0 reduce el coste temporal 
a expensas de aumentar el almacenamiento y el número de 
tripletas enviadas (cosa que podría llegar a causar un cuello 
de botella). 

Cuando la memoria disponible es limitada tenemos dos 
opciones. La primera consiste en tomar el valor más grande 
posible de O tal que el almacenamiento previsto necesario 
(expresión 3) corresponda con la memoria disponible. La 
segunda opción (sugerida en [6]) es la de tomar un Q más 
grande y añadir tripletas a la lista hasta que la memoria se 
agote. A partir de este momento, cada vez que se deba guardar 
una tripleta nueva, se eliminará alguna de las almacenadas 
previamente. 

Esta propuesta proporciona un speedup que al aumentar 
linealmente con el número de procesadores resulta eficiente. 
Por otro lado, el almacenamiento de tripletas distinguidas 
obliga a disponer de un espacio de memoria cuyo tamaño 
repercute en el coste temporal del algoritmo (a mayor tamaño, 
menor es el tiempo de ejecución). 


(3) 


TV. NUEVA PROPUESTA 


En este trabajo se presenta una nueva forma de paralelizar 
el algoritmo Rho de Pollard con speedup proporcional al 
número de procesadores y cuyos requisitos de memoria son 
muy reducidos. 

En esta nueva propuesta, cada uno de los procesadores 
ejecuta el algoritmo de Pollard buscando la colisión de dos 
tripletas mediante el algoritmo de Brent tomando una tripleta 
al azar como punto de partida de su secuencia. Sin añadir nada 
más, esto sería una simple paralelización trivial con la cual se 
obtendría un speedup proporcional a YM. 

Para aumentar el speedup y hacerlo proporcional a M 
nuestra propuesta modifica la paralelización trivial haciendo 
que en cada iteración, un procesador comprueba, no solamente 
si su liebre ha alcanzado a su tortuga, sino si su liebre ha 
alcanzado a su propia tortuga o a la de cualquier otro de los 
procesadores. 

En el algoritmo 3 se da una descripción formal de la prop- 
uesta suponiendo que se dispone de un espacio de memoria 
compartido entre todos los procesadores donde cada uno de 
ellos tiene una celda reservada donde almacena el valor de 
su tripleta “tortuga”. El uso de este espacio de memoria 
compartido permite que esta paralelización tenga los mismos 
requisitos de memoria que la paralelización trivial. Para una 
implementación eficiente, este espacio de memoria debe ser 
implementado utilizando una estructura de datos de acceso 
rápido como por ejemplo un hash [12]. 


Algorithm 3 Nueva propuesta para la paralelización del 


algoritmo Rho de Pollard 


Input: Un grupo G de orden p y dos elementos g,h € G 
Output: El logaritmo discreto m = log, h 


1 Cada Procesador 2 hace: 


2 Escoger az,bz € [0,p—1] al azar; 

3 Calcular x, =g“ hoz; 

4 Almacenar (x,,aL,b,) en la celda ¿ de memoria; 

5  (21,01,b1):=F(x1,aL,bL); 

6 Longitud := Pasos := 1; 

7 while No haya una tripleta (x;,a;,b;) con 1; = "1 
en memoria do 

8 if Pasos=Longitud then 

9 Almacenar (x,,aL,b,) en la celda ¿ de 

memoria; 

10 Longitud := 2 * Longitud; 

11 Pasos := 0; 

12 end 

13 (x,,aL,b1) =Fl(zL,aL,bL); 

14 Pasos := Pasos + 1; 

15 end 

16 Recuperar la tripleta (27, ay, by) con uy =x1 de 
memoria; 

17 — Ordenar a todos los procesadores que se detengan; 

18 Calcular m := (ay — az)(bz — by) * (mód p); 

19 return mm; 


V. RESULTADOS EXPERIMENTALES 


El algoritmo 3 ha sido implementado en C++ para resolver 
un logaritmo discreto planteado sobre un subgrupo de orden 
primo del grupo multiplicativo |F?, con q primo, utilizando la 
librería de números grandes NTL [5]. Dado que el algoritmo 
es de tipo heurístico, cada experimento se ha repetido veinte 
veces, variando al azar las tripletas de inicio, y se ha calculado 
el tiempo medio de ejecución. 


V-A. Resultados en un multicomputador de memoria com- 
partida 


A continuación se presentan los resultados obtenidos en 
una implementación para un multicomputador de memoria 
compartida formado por dos procesadores Intel Xeon de 3.16 
GHz de cuatro núcleos cada uno (disponiendo así de un total 
de ocho núcleos de cálculo). La zona de memoria donde se 
almacenan las tortugas se ha implementado sobre un segmento 
de memoria compartida. En el cuadro I se muestran los 
resultados. 

Para cuantificar el descenso en el tiempo de ejecución, se 
han calculado los speedup que se muestran en el Cuadro IT. La 
obtención, en algunos casos, de valores de speedup superiores 
al número de procesadores se debe a que estamos trabajando 
con un algoritmo cuyo tiempo de ejecución es aleatorio y con 
una varianza muy elevada (en algunos casos, para la resolución 
del mismo problema se han obtenido tiempos tan distintos co- 
mo 362 y 1570 segundos). La conclusión importante, más que 
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Número de procesadores 
Bits 1 2 + 6 8 
52 189 87 31 19 17 
56 1119 438 194 136 sl 
60 1101 722 437 297 | 269 
64 13210 | 5281 | 1906 | 1600 | 741 
Cuadro 1 


TIEMPO MEDIO (EN SEGUNDOS) NECESARIO PARA RESOLVER UN 
LOGARITMO DISCRETO SOBRE UN GRUPO MULTIPLICATIVO F¿, CON q 
PRIMO DE 52, 56, 60 Y 64 BITS DE LONGITUD EN UN MULTICOMPUTADOR 
DE MEMORIA COMPARTIDA. 


los valores concretos de speedup obtenidos, es su tendencia 
a aumentar linealmente respecto al número de procesadores 
utilizado. 


| Número de procesadores | 
Bis |2]14]6] 37] 
52 2.2 | 6.1 10 11.1 
56 2.5 | 5.8 | 8.2 13.9 
60 115125 37 | 4.1 
64 2 7 8.3 17.8 
Cuadro II 


SPEEDUP DEL ALGORITMO PARALELIZADO EN UN MULTICOMPUTADOR DE 
MEMORIA COMPARTIDA. 


V-B. Resultados en un multicomputador de memoria dis- 
tribuida 


Los mismos experimentos se han llevado a cabo en un 
cluster formado por ocho nodos con procesadores Intel Core 2 
Quad de 2.4 GHz interconectados a través de una red Gigabit 
Ethernet. La implementación para esta plataforma se ha hecho 
en C++ utilizando la librería de comunicaciones MPI [3]. La 
compartición de tripletas tortuga se ha implementado de tal 
forma que cada procesador dispone de una copia de todas 
las tripletas tortuga. Para mantener la coherencia de estos 
datos, cada vez que un procesador actualiza su tripleta tortuga, 
informa al resto de procesadores mediante el envío de un 
mensaje broadcast. Los tiempos medios y speedup obtenidos 
se hallan listados en los cuadros III y IV, respectivamente, 
y permiten reafirmar las conclusiones obtenidas en el primer 
experimento. En este entorno, la paralelización presenta un 
rendimiento (speedup) menor debido a la penalización que 
conlleva que la comunicación entre procesos deba realizarse 
mediante envío de mensajes. 


Número de procesadores 
Bits 1 2 4 6 8 
32 240 159 51 39 37 
56 1085 697 288 245 284 
60 1967 1093 801 626 551 
64 16884 | 7571 | 5707 | 3132 | 2139 
Cuadro HI 
TIEMPO MEDIO (EN SEGUNDOS) NECESARIO PARA RESOLVER UN 
LOGARITMO DISCRETO SOBRE UN GRUPO MULTIPLICATIVO Fago CON q 


PRIMO DE 52, 56, 60 Y 64 BITS DE LONGITUD EN UN ENTORNO MPI. 


| Número de procesadores 

[| Bits 2 4 6 8 
52 15 47 6.2 6.5 
56 16 38 44 3.8 
60 18 | 2.5 | 3.1 3.6 
64 2.2 3 5.4 7.9 


Cuadro IV 
SPEEDUP DEL ALGORITMO PARALELIZADO EN UN ENTORNO MPTI. 


VI. CONCLUSIONES Y TRABAJO FUTURO 


En este artículo se ha presentado una nueva forma de 
paralelizar el algoritmo Rho de Pollard con la cual se obtiene 
un speedup proporcional al número de procesadores utilizados 
y cuyos requisitos de memoria son los mismos que en una 
paralelización trivial. 

Como trabajo futuro se plantea el estudio del rendimiento de 
este método en entornos heterogéneos donde los computadores 
se encuentran distribuidos geográficamente e interconectados 
a través de Internet (grid computing). 
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Resumen—La firma electrónica se ha convertido en un elemen- 
to fundamental en la sociedad de la información, disfrutando del 
reconocimiento como medio de prueba en procedimientos legales. 
Así mismo, la firma electrónica es considerada una evidencia 
de no repudio respecto a los compromisos adquiridos por los 
participantes en una transacción electrónica. Sin embargo, la 
realidad nos muestra que la tecnología no está libre de vulnerabi- 
lidades, existiendo múltiples amenazas que pueden comprometer 
la seguridad de los sistemas. Es por tanto imprescindible disponer 
de las herramientas adecuadas que asistan al desarrollo de 
sistemas seguros, de forma que pueda aplicarse la legislación 
con plenas garantías para las partes implicadas. En particular, 
el proceso de generación de la firma es una de las etapas más 
sensibles, y a la cual se debe prestar especial atención. En este 
artículo se presenta la primera taxonomía completa de ataques a 
entornos de creación de firma, y que permitirá el análisis riguroso 
y sistemático de las causas que pueden socavar la fiabilidad de 
la misma, y así poder actuar en consecuencia. 


Í. 


Una taxonomía es un sistema o esquema para la clasi- 
ficación sistemática del conocimiento. Mediante un análisis 
riguroso y sistemático, dicho conocimiento es clasificado en un 
conjunto limitado de categorías bien definidas. De esta forma, 
una taxonomía permite descomponer conceptos o fenómenos 
complejos en unidades de información más abordables, no sólo 
permitiendo su estudio sino también proporcionando una base 
de partida común sobre la cual analizar y clasificar hechos 
desconocidos hasta el momento. 

Para que una taxonomía sea útil, debe estar muy espe- 
cializada en un área de conocimiento o fenómeno concreto. 
Hasta la fecha se ha propuesto un gran número de taxo- 
nomías centradas en los sistemas de la información, así como 
taxonomías focalizadas en el área de la seguridad. Existen 
taxonomías para la clasificación de sistemas de detección de 
intrusiones [11], errores y vulnerabilidades en los sistemas 
[12], [13], [14], ataques software [16], incidentes de seguridad 
en redes de comunicaciones [15], [17] o ataques a dispositivos 
seguros [21]. Estas taxonomías han permitido profundizar en 
el estudio de múltiples problemáticas de seguridad mediante 
la categorización de ataques y vulnerabilidades. 

En cuanto a taxonomías relacionadas con firma electrónica, 
Kain propuso en 2003 una taxonomía no formal de ataques a 
firmas electrónicas mediante la manipulación del documento 
a firmar [19]. Sin embargo, la taxonomía no es completa, y se 
centra exclusivamente en ataques que modifican la semántica 
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del documento, obviando otros muchos tipos de ataque po- 
sibles. Otros investigadores han estudiado vulnerabilidades y 
ataques a tarjetas inteligentes [20], cuyo compromiso clara- 
mente afecta a la fiabilidad de la firma electrónica, aunque sólo 
unos pocos han proporcionado una clasificación rigurosa de 
ataques a dichos dispositivos [21]. Por otra parte, numerosos 
trabajos se han centrado en los ataques de canal indirecto, 
los cuales tienen un gran impacto en la seguridad de los 
dispositivos criptográficos [22]. 

Sin embargo, a día de hoy no se ha propuesto ninguna taxo- 
nomía que abarque de forma integral y rigurosa los problemas 
de seguridad que afectan a la firma electrónica. El presente 
artículo pretende dar respuesta a esta necesidad, ya que las 
firmas electrónicas se han convertido en un elemento clave en 
múltiples escenarios, pero todavía no se ha estudiado de forma 
sistemática las amenazas que pueden influir en la fiabilidad 
de las mismas. Deseamos que la taxonomía aquí propuesta 
sirva de guía para diseñar soluciones de firma más seguras y 
robustas, una vez conocidos los riesgos existentes. 

El artículo recoge en primer lugar la motivación en la 
Sección II. Posteriormente, la Sección III acota el modelo de 
sistema que tomaremos como objeto de estudio para definir 
la taxonomía. La Sección IV propone la primera taxonomía 
completa de ataques a entornos de creación de firma. La eva- 
luación de la taxonomía frente a los requisitos fundamentales 
para taxonomías se incluye en la Sección V. Por último, se 
concluye el artículo en la Sección VI. 


TT. 


La firma electrónica se ha convertido en un elemento fun- 
damental en la sociedad de la información. Numerosas legis- 
laciones de todo el mundo han otorgado a la firma electrónica 
una equivalencia funcional respecto a la firma manuscrita, 
así como un reconocimiento como mecanismo de seguridad 
primordial en transacciones electrónicas, especialmente dentro 
del ámbito del comercio electrónico [2], [3], [4], [5], [6]. 

En el caso particular de las legislaciones Europea y Es- 
pañola, la firma electrónica disfruta de plena eficacia jurídica, 
pudiendo ser empleada como medio de prueba en procedi- 
mientos legales [7]. Dependiendo de los requisitos cumplidos 
por la firma en cuestión, ésta contará con un juicio favorable de 
validez a priori (ex ante) o necesitará de un juicio a posteriori 
(ex post) del Tribunal. En el primer caso, si el supuesto 
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firmante repudiara el compromiso adquirido en un documento 
firmado, debería aportar evidencias en sentido contrario y que 
generaran una duda razonable respecto a la seguridad de la 
firma. Así pues, la carga de prueba en este escenario recae 
sobre el supuesto firmante que niega la validez de la firma 
[1]. En el segundo caso, el supuesto firmante podría también 
repudiar la autoría de dicha firma pero sería la otra parte 
afectada quien debiera aportar garantías sobre la seguridad de 
la misma. 

En esta línea, existe también un reconocimiento en los 
estándares internacionales de proporcionar a las firmas 
electrónicas (criptográficas) la cualidad de evidencia de no 
repudio [8]. Una evidencia de no repudio es información que, 
bien por sí misma o usada en conjunción con otros datos, 
se emplea para probar la ocurrencia de un evento o acción. 
Aunque la evidencia no prueba necesariamente por sí misma 
la veracidad del hecho, sí es usada para tal fin. Por tanto, 
una evidencia de no repudio que se verifica correctamente de 
acuerdo a la política de no repudio que aplica es suficiente para 
resolver una posible disputa, impidiendo al firmante repudiar 
el compromiso adquirido en la transacción. 

Así pues, consideramos imprescindible disponer de las he- 
rramientas adecuadas para el estudio riguroso del problema de 
seguridad de las firmas electrónicas, con el fin de poder asistir 
al desarrollo de sistemas más seguros que permitan aplicar la 
legislación con plenas garantías para las partes afectadas. En 
este sentido, una taxonomía de ataques permitirá conocer dicha 
problemática, y actuar en consecuencia. Dicha taxonomía no 
se ha propuesto hasta la fecha. 

La taxonomía aquí presentada considera firmas electrónicas 
generadas mediante criptografía asimétrica (firmas digitales), 
al ser no sólo una de las posibles tecnologías concretas de 
implementación sino también la única tecnología que, a día de 
hoy, es capaz de alcanzar determinados requisitos establecidos 
en la legislación. En particular, la taxonomía se centra en una 
de las etapas más sensibles del ciclo de vida de una firma, 
esto es, la fase de generación. 


TIT. MODELO DE SISTEMA 


La Figura 1 muestra el modelo de sistema que tomamos 
como punto de partida para el estudio de los ataques al 
entorno de creación de firmas. Dicho modelo se sustenta en 
el propuesto en el estándar CEN CWA 14170 [9]. 

La aplicación de creación de firma (SCA) es la aplicación 
dentro del sistema (SCS) que incorpora la funcionalidad de 
generación de firmas electrónicas, apoyándose en el dispositivo 
(seguro) de creación de firmas (S)SCDev. El entorno de 
creación de firmas (SCE) incluye los entornos físico y lógico 
del SCS, así como el firmante y las políticas existentes. El 
SCDev es el dispositivo software o hardware que incorpora 
los datos de creación de firma (SCD), es decir, la clave 
privada de firma usada por el firmante para generar las firmas 
electrónicas. El SSCDev es un SCDev que cumple con los 
requisitos estipulados en el Anexo III de la Directiva Europea 
de firma [2]. El acceso al SCD se protege mediante los datos 
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Figura 1. Modelo de Sistema 


de autenticación del firmante (SAD), consistentes en un PIN 
o contraseña. 

En este artículo nos referimos al término DT'BS cuando 
los datos a firmar incorporan tanto el documento en sí como 
una serie de atributos de firma que enriquecen la semántica 
de dicho documento o particularizan el compromiso adquirido 
en el acto de firma. Por otra parte, DTBSR se referirá a la 
representación del DTBS que se envía al SCDev/SSCDev para 
el cómputo de la firma - generalmente se corresponderá con 
el resumen criptográfico del DTBS. 


IV. TAXONOMÍA DE ATAQUES A ENTORNOS DE 
CREACIÓN DE FIRMA 


La taxonomía aquí propuesta toma como modelo de sistema 
el descrito en la Sección III. Así pues, la taxonomía categoriza 
ataques orientados a comprometer la seguridad del proceso de 
generación de firmas electrónicas llevado a cabo en un sistema 
que cumple el modelo indicado. 

En particular, la taxonomía está formada por cuatro di- 
mensiones, que se detallan en las siguientes subsecciones. El 
concepto de dimensión fue introducido por Landwehr et al. 
[12], y es una propiedad que permite la clasificación de un 
ataque o vulnerabilidad desde un punto de vista integral. Cada 
ataque se descompone en varias propiedades, y cada propiedad 
se emplea para clasificar el ataque desde una perspectiva 
diferente, todas complementarias entre sí. 

Las categorías tienen un identificador asociado consistente 
en el número de dimensión en el que están englobadas (D) y el 
número de categoría o subcategoría según el orden jerárquico 
establecido (CAT). 


IV-A. Dimensión Objetivo del Atacante 


Esta dimensión cubre el objetivo final del atacante. 
Identificamos tres categorías dentro de esta dimensión: 


D1-CAT1: Firma no consciente de datos 

El atacante no hace uso directo de los datos de creación de 
firma pero desea engañar al firmante para que, de forma no 
consciente, firme ciertos datos. 


D1-CAT?2: Uso no autorizado de los datos de creación de 
firma (SCD) 

El atacante desea emplear los datos de creación de firma sin 
el conocimiento ni consentimiento del firmante. Para ello, el 
atacante necesitará bien comprometer directamente los datos 
de creación de firma bien tener acceso a la operación de firma. 


D1-CAT3: Sustitución/Modificación de datos firmados 
El atacante desea sustituir o modificar parte o la totalidad de 
los datos firmados, pero una vez que la firma se ha realizado. 


IV-B. Dimensión Método de Ataque 


Esta dimensión incluye las categorías de método de ataque 
empleado por el atacante para conseguir uno de los objetivos 
anteriormente identificados. En concreto, se han diseñado 
cinco categorías de primer nivel, que se refinan a su vez en 
subcategorías, y así hasta un cuarto nivel de profundidad en 
algunos casos: 


D2-CAT1: Manipulación del entorno 

Esta categoría abarca los métodos que pretenden manipular 
el entorno (principalmente la Plataforma del SCS) con el 
fin de influenciar en los datos firmados, bien sea durante la 
generación de la firma o con posterioridad. 


D2-CAT2: Modificación previa a la generación de la firma 

Esta categoría contiene los métodos de ataque que intervie- 
nen antes de la generación de la firma, y cuyo objetivo es la 
modificación de los datos a firmar, bien sea de forma directa 
(modificación del propio contenido a firmar) o indirecta (los 
datos fraudulentos se incorporan por referencia desde los datos 
a firmar). 

D2-CAT?2.1: Modificación de documento. Esta subcategoría 
de métodos se refiere a las modificaciones realizadas en el 
documento a firmar. 

D2-CAT?2.1.1: Adición de contenido dinámico. Esta subca- 
tegoría de métodos implica la inclusión de contenido dinámico 
en el documento a firmar. De esta forma, la sintaxis del 
documento se mantiene intacta, y por tanto la integridad de 
la firma, mientras que la semántica variará de acuerdo al 
comportamiento del código dinámico. 

D2-CAT?.1.1.1: Código oculto. El atacante inserta etiquetas 
especiales o campos ocultos en el documento a firmar. Este 
código oculto será traducido por determinados valores depen- 
diendo de condiciones específicas que pueden ser controladas 
por el atacante. 

D2-CAT?2.1.1.2: Código activo. El atacante inserta código 
especial, como scripts o macros, en el documento a firmar. 
Este código se ejecutará durante la apertura o visualización 
del documento, pudiendo realizar ciertas operaciones como la 
modificación del contenido mostrado. 
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D2-CAT?2.1.1.3: Vínculos. El atacante inserta vínculos en 
el documento a firmar que apuntan a contenido externo no 
controlado por el firmante. Una vez realizada la firma, el 
atacante puede manipular dicho contenido externo a su antojo. 

D2-CAT?2.1.2: Modificación de contenido. El atacante mo- 
difica el contenido del documento a firmar, pero sin incluir 
ningún tipo de contenido dinámico (p. e. modificación del 
propio texto del documento). 

D2-CAT2.2: Modificación de atributo. Esta subcategoría 
de métodos se refiere a las modificaciones realizadas en los 
atributos a firmar. 

D2-CAT?2.2.1: Adición de contenido dinámico. Esta subca- 
tegoría de métodos implica la inclusión de contenido dinámico 
en los atributos a firmar. El comportamiento es igual que 
en el caso anterior para el documento, pero enfocado en los 
atributos. 

D2-CAT?2.2.1.1: Código oculto. El atacante inserta etiquetas 
especiales o campos ocultos en los atributos a firmar. Este 
código oculto será traducido por determinados valores depen- 
diendo de condiciones específicas que pueden ser controladas 
por el atacante. 

D2-CAT?2.2.1.2: Código activo. El atacante inserta código 
especial, como scripts o macros, en los atributos a firmar. Este 
código se ejecutará durante la visualización o aplicación de 
los atributos, pudiendo realizar ciertas Operaciones como la 
modificación del contenido mostrado. 

D2-CAT?2.2.1.3: Vínculos. El atacante inserta vínculos en 
los atributos a firmar que apuntan a contenido externo no 
controlado por el firmante. Una vez realizada la firma, el 
atacante puede manipular dicho contenido externo a su antojo. 

D2-CAT?2.2.2: Modificación de contenido. El atacante mo- 
difica el contenido de los atributos a firmar, pero sin incluir 
ningún tipo de contenido dinámico (p. e. modificación del 
valor de cierto atributos). 

D2-CAT2.3: Modificación de DTBS. El atacante modifica 
la información contenida en la estructura que representa los 
datos a firmar (DTBS). 

D2-CAT?2.4: Modificación de DTBSR. El atacante modifica 
el resumen de los datos a firmar (DTBSR). Este ataque se 
produciría en la última etapa antes de la computación de firma. 


D2-CAT3: Modificación posterior a la generación de la 
firma 

Esta categoría contiene métodos de ataque ejecutados una 
vez que la firma ha sido realizada, y cuyo objetivo es la 
modificación de los datos ya firmados, bien sea de forma 
directa (modificación del propio contenido firmado) o indirecta 
(modificación de datos referenciados desde los datos firma- 
dos). 

D2-CAT3.1: Contenido externo. El atacante modifica datos 
externos referenciados desde los datos firmados (p. e. XSD, 
DTD). La diferencia entre este método y D2-CAT2.1.1.3: 
Vínculos o D2-CAT2.2.1.3: Vínculos radica en que, en este 
método, el vínculo a los datos externos no se incluye por el 
atacante, mientras que en estos otros dos casos, es el atacante 


quien, de forma explícita, inserta dicho vínculo al contenido 
externo. 

D2-CAT3.2: Criptoanálisis. El atacante aplica métodos de 
criptoanálisis para obtener un documento o atributos diferentes 
a los firmados de forma que no se invalide la firma. 

D2-CAT3.2.1: Función resumen. El atacante aplica métodos 
específicamente diseñados para romper la seguridad de la 
función resumen empleada en el cálculo de la firma. 

D2-CAT3.2.1.1: Ataque de colisión. El atacante es capaz de 
encontrar un par de mensajes M 4 M” donde hash(M) = 
hash(M”) con una complejidad menor a O(2"/?) (p. e. ataque 
del cumpleaños). 

D2-CAT3.2.1.2: Ataque de preimagen. El atacante, dado un 
valor resumen A, es capaz de encontrar un mensaje M” donde 
hash(M”) = H con una complejidad menor que O(2”). 

D2-CAT3.2.1.3: Ataque de segunda preimagen. El atacante, 
dado un mensaje /M, es capaz de encontrar un segundo 
mensaje M', M' 4 M, que satisfaga hash(M) = hash(M”) 
con una complejidad menor que O(2”). 


D2-CAT4: Invocación no autorizada de la operación de 
firma 

Esta categoría recoge los métodos de ataque que no posi- 
bilitan al atacante conocer el SCD pero sí hacer uso de él sin 
el conocimiento ni consentimiento del usuario. 

D2-CAT4.1: Compromiso de datos de autenticación de 
firmante (SAD). Esta subcategoría cubre los métodos que 
permiten al atacante recuperar el SAD. 

D2-CAT4.1.1: Ingeniería social. El atacante manipula o 
engaña al firmante para que éste revele el SAD. 

D2-CAT4.1.2: Intercepción del SAD. El atacante intercepta 
el SAD durante la operación del SCS. 

D2-CAT4.1.2.1: Observación. El atacante observa al firman- 
te introducir el SAD en la Plataforma. 

D2-CAT4.1.2.2: Intercepción de comunicación entre pro- 
cesos/entidades. El atacante intercepta el SAD durante su 
transmisión entre dos procesos o entidades físicos o lógicos 
que pertenecen al SCS. 

D2-CAT4.1.2.3: Compromiso de extremo. Mediante el com- 
promiso de la seguridad de un extremo (proceso o entidad que 
interviene en la comunicación del SAD dentro del SCS), el 
atacante es capaz de interceptar el SAD. 

D2-CAT4.1.3: Obtención por prueba y error. El atacante 
emplea métodos probabilísticos (p. e. ataque de diccionario), 
técnicas de análisis de emanaciones acústicas del teclado o 
simplemente un ataque por fuerza bruta para adivinar el SAD. 

D2-CAT4.2: Evitación de Autenticación. El atacante evita 
la autenticación para acceder a la operación de firma. 


D2-CAT5: Compromiso de datos de creación de firma 
(SCD) 

Esta categoría incluye métodos que permiten al atacante 
obtener el SCD. Esta es la categoría que aglutina los métodos 
de ataque más peligrosos, dado que el atacante podría, una vez 
conocido el SCD, realizar tantas firmas en nombre del usuario 
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legítimo como deseara, incluso desde un entorno diferente al 
SCE. 

D2-CAT5.1: Intercepción del SCD. El atacante intercepta el 
SCD durante el proceso de creación o distribución. 

D2-CATS5.1.1: Intercepción de comunicación entre proce- 
sos/entidades. El atacante intercepta el SCD durante su trans- 
misión entre dos procesos o entidades físicos o lógicos que 
pertenecen al SCS. 

D2-CATS5.1.2: Compromiso de extremo. Mediante el com- 
promiso de la seguridad de un extremo (proceso o entidad 
que interviene en la comunicación del SCD dentro del SCS), 
el atacante es capaz de interceptar el SCD. 

D2-CATS5.2: Eavesdropping (ataque de canal indirecto). Los 
ataques de canal indirecto explotan el filtrado de informa- 
ción en base a las características del dispositivo hardware 
usado durante la ejecución de los algoritmos criptográficos. 
De esta manera, la clave privada puede llegar a conocerse. 
La importancia de este tipo de ataques radica en que la 
complejidad o robustez del algoritmo criptográfico no afecta 
al éxito del ataque, dado que el fundamento de los ataques de 
canal indirecto reside en la dependencia entre la información 
procesada (p. e. la clave privada de firma) y/o las operaciones 
realizadas por el dispositivo (p. e. tarjeta inteligente) con el 
comportamiento del hardware subyacente. 

D2-CATS5.2.1: Tiempo. Un ataque de análisis de tiempo 
explota los tiempos de ejecución medidos para un cierto 
número de operaciones. 

D2-CATS5.2.2: EMA. Un ataque de análisis electromagnéti- 
co (EMA) explota la correlación entre los datos secretos y las 
variaciones en las radiaciones emitidas por los dispositivos. 

D2-CATS5.2.3: Potencia. Un ataque de análisis de poten- 
cia analiza la relación entre el consumo de potencia de un 
dispositivo criptográfico y los datos manejados durante las 
operaciones criptográficas. 

D2-CAT5.2.4: Microarquitectural. Un ataque de análisis 
microarquitectural estudia los efectos que los componentes 
pertenecientes a los procesadores comunes y su funcionalidad 
tienen sobre la seguridad de los criptosistemas software. 

D2-CATS5.2.5: Observación óptica. Las emanaciones ópticas 
también pueden filtrar información al atacante. En caso que 
los datos procesados por un dispositivo que emanara este tipo 
de señales se correspondieran con el SCD, el atacante podría 
comprometerlo. 

D2-CATS5.3: Acceso no autorizado al SCDev. El atacante 
compromete el SCD accediendo al SCDev donde se almacena. 

D2-CATS5.3.1: Compromiso de datos de autenticación de 
firmante (SAD). El atacante es capaz de extraer el SCD una 
vez conocido el SAD. Este método de ataque requiere que el 
SCD sea exportable. Esta subcategoría se ramifica a su vez 
en las mismas subcategorías que D2-CAT4.1 Compromiso de 
datos de autenticación de firmante (SAD). 

D2-CATS5.3.2: Evitación de Autenticación. El atacante es 
capaz de acceder al SCD (y leerlo) incluso sin necesidad de 
conocer el SAD. Este método de ataque requiere que el SCD 
pueda ser leído. 


D2-CATS5.4: Criptoanálisis. El atacante aplica métodos de 
criptoanálisis para conocer el SCD. 

D2-CATS5.4.1: Algoritmo asimétrico. Esta subcategoría 
recopila cualquier ataque centrado en comprometer la clave 
privada usada en el algoritmo asimétrico concreto. Existen 
múltiples algoritmos asimétricos que pueden emplearse para 
realizar una firma electrónica basada en criptografía (p. e. 
RSA, DSA, curva elíptica, etc.). Dependiendo del algoritmo, 
el conjunto de posibles métodos de ataque variará. 


No todos los métodos de ataque pueden permitir al ata- 
cante alcanzar los tres objetivos establecidos en la primera 
dimensión. El Cuadro I relaciona las categorías de la primera 
dimensión con las categorías de primer nivel de la segunda 
dimensión. 


IV-C. Dimensión Patrón de Ataque 


Un patrón de ataque describe cómo un tipo de ataque 
observado se lleva a cabo. Es la descripción del mecanismo 
empleado para explotar un sistema pero desde el punto de vista 
del atacante. CAPEC (Common Attack Pattern Enumeration 
and Classification) [10] es una extensa colección de patrones 
de ataque que se considera un referente a nivel mundial. Es una 
base de datos pública y cuyos patrones de ataque se generan 
tras un análisis exhaustivo de ataques reales. Para cada patrón 
de ataque se proporcionan datos relevantes como el flujo de 
ejecución del ataque o los requisitos que deben cumplirse para 
que el ataque pueda ser llevado a cabo. 

En esta dimensión se incluye una selección de patrones de 
ataque de entre los 287 existentes actualmente en CAPEC. 
El criterio de selección no ha sido otro que el análisis de 
aplicabilidad de cada patrón de ataque en base al modelo de 
sistema planteado, y cuya instanciación pudiera comprometer 
la seguridad de un proceso de generación de firma. Se han 
identificado 192 patrones de ataque válidos que, por cuestiones 
de espacio, no se incluyen en el artículo. 


IV-D. Dimensión Objeto del Ataque 


Esta dimensión categoriza los posibles elementos que pue- 
den ser objeto del ataque. Un ataque puede afectar a uno o 
varios elementos, por lo que la clasificación de un ataque 
podría necesitar la selección de varias categorías de esta 
dimensión (véase Sección IV-E). 

Por cuestiones de espacio y relevancia en relación con otras 
dimensiones, no se proporciona un listado de las categorías 
existentes ni una descripción de las mismas. Simplemente se 
indican a continuación las categorías de primer nivel: D4- 
CATI: Criptografía, D4-CAT2: Software, D4-CAT3: Hardwa- 
re, D4-CAT4: Usuario. 


IV-E. Método de Clasificación 


El método de clasificación de una taxonomía debe guiar 
a un usuario de forma clara y unívoca en la clasificación 
de un nuevo elemento. Para clasificar un ataque en base a 
la taxonomía aquí presentada, deben seguirse los siguientes 
pasos: 
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. Debe identificarse el objetivo del ataque, y clasificarse 
de acuerdo a la dimensión Objetivo del Atacante. 

Una vez conocido el objetivo, debe clasificarse el méto- 
do empleado por el atacante para alcanzar dicho objeti- 
vo, de acuerdo a la dimensión Método de Ataque, y la 
Tabla I. El método debe clasificarse en la subcategoría 
de mayor profundidad posible. 

El patrón de ataque concreto empleado debe seleccio- 
narse de acuerdo a la dimensión Patrón de Ataque y la 
información existente en la base de datos de CAPEC. 
Al igual que en el caso del método, debe seleccionarse 
el patrón de ataque más concreto posible. 

Deben identificarse los elementos del SCE que se ven 
afectados de forma directa o indirecta por el ataque, y 
clasificarse en base a la dimensión Objeto del Ataque. 
En caso que el ataque afecte a más de un elemento, 
deberán seleccionarse varias instancias (categorías) de 
esta dimensión. 

En cada paso, si se detecta la necesidad de añadir una 
nueva categoría o subcategoría, ésta debe incorporarse a 
la taxonomía, y clasificar el ataque como corresponda. 


Así pues, un ataque se clasificará con una categoría de 
la dimensión Objetivo del Atacante, una (sub)categoría de 
la dimensión Método de Ataque, una (sub)categoría de la 
dimensión Patrón de Ataque, y una O varias (sub)categorías 
de la dimensión Objeto del Ataque. 


V. EVALUACIÓN DE LA TAXONOMÍA 


Una taxonomía debe satisfacer una serie de requisitos gene- 
rales [18]. Una taxonomía debería ser ampliamente aceptada 
en el campo de aplicación. La taxonomía propuesta se funda- 
menta en trabajos previos que han tenido un fuerte impacto 
en la comunidad científica. Así mismo, la taxonomía aplica el 
diseño basado en dimensiones, que ha demostrado ofrecer una 
perspectiva integral del campo de estudio abordado. Por ello, 
y por la falta actual de una taxonomía centrada en ataques a 
firma electrónica, creemos que la taxonomía aquí propuesta 
será un primer paso en el estudio de esta problemática. 

La taxonomía debería ser exhaustiva en el sentido de que 
pudiera cubrir la clasificación de cualquier elemento dentro 
del campo de estudio. Este requisito es difícil de cumplir 
dado que no es posible conocer todos los ataques existentes a 
firmas electrónicas, especialmente en un campo tan dinámico 
como el de la seguridad. Sin embargo, la evaluación de la 
taxonomía frente ataques reales es fundamental para verificar 
su completitud. En este sentido, se ha llevado a cabo de forma 
satisfactoria una clasificación de 70 ataques encontrados en la 
literatura, pero que, por motivos de espacio, no se incluyen en 
el artículo. 

Las categorías de la taxonomía deberían ser excluyentes 
entre sí, de forma que cada ataque fuera clasificado exclusi- 
vamente en una categoría de cada dimensión. El diseño de la 
taxonomía y el método de clasificación aseguran este principio. 
La posibilidad de seleccionar varias categorías en la dimensión 
Objeto del Ataque no implica que se viole este requisito, sino 


Objetivo 


Método 


D1-CAT!: Firma no consciente de datos 


D2-CATI: Manipulación del entorno 
D2-CAT?2: Modificación previa a la generación de la firma 


D1-CAT?2: Uso no autorizado de los datos de creación de firma (SCD) 


D2-CAT4: Invocación no autorizada de la operación de firma 
D2-CATS5: Compromiso de datos de creación de firma (SCD) 


D1-CAT3: Sustitución/Modificación de datos firmados 


D2-CAT3: Modificación posterior a la generación de la firma 


Cuadro I 
RELACIÓN ENTRE DIMENSIÓN OBJETIVO Y DIMENSIÓN MÉTODO 


que la taxonomía permite la clasificación de varios elementos 
afectados por el ataque si fuera necesario. 

El método de clasificación debería ser determinista y repe- 
tible en base al diseño de la taxonomía. El método aquí pro- 
porcionado es claro, sencillo e inequívoco teniendo en cuenta 
las dimensiones diseñadas. 

La taxonomía debería emplear terminología ampliamente 
aceptada y ser apropiada, basándose en un modelo claro de 
referencia. La terminología y modelo de sistema empleados en 
la presente taxonomía se derivan de los estándares actuales. 
Así mismo, el modelo acota exactamente los elementos de alto 
nivel que intervienen y las relaciones entre ellos. 

Para ser útil, una taxonomía debería estar especializada 
en un área de conocimiento concreta. En nuestro caso, la 
taxonomía se centra en ataques a entornos de creación de 
firmas electrónicas basadas en criptografía de clave pública. 

Por último, la taxonomía debería ser útil. En este sentido, 
la taxonomía propuesta permite la clasificación sistemática de 
ataques a entornos de creación de firmas, lo cual sin duda 
redundará en un mayor conocimiento a la hora de diseñar 
soluciones más eficaces no sólo contra ataques conocidos sino 
contra ataques potenciales todavía por aparecer. 


vI. 


La importancia de la firma electrónica, con su amplio 
reconocimiento por las legislaciones y estándares internacio- 
nales vigentes, así como las consecuencias que de ella se 
derivan, nos llevan a la necesidad de diseñar sistemas y 
soluciones robustos ante las amenazas existentes y futuras, 
por otra parte numerosas. Una taxonomía de ataques permitiría 
categorizar los ataques posibles de forma genérica y abstracta, 
beneficiando el estudio de contramedidas globales aplicables 
a cualquier entorno de firma. 

Aunque se han propuesto numerosas taxonomías en el 
ámbito de la seguridad, ninguna ha abordado de manera 
integral el problema de seguridad de las firmas electrónicas. En 
este artículo se ha presentado la primera taxonomía de ataques 
a entornos de creación de firma electrónica. La taxonomía se 
ha dividido en cuatro dimensiones, lo cual permite el análisis 
y clasificación de ataques desde un punto de vista holístico. 
La taxonomía se ha validado satisfactoriamente frente a los 
requisitos y principios fundamentales para taxonomías, inclu- 
yendo el requisito de completitud mediante la clasificación de 
setenta ataques publicados en la literatura (no incluidos en el 
presente artículo). 

Como trabajo futuro se ampliará la taxonomía incorporando 
categorías de ataque orientados a la fase de verificación (p. e. 
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aprovechar la latencia en la actualización de CRL para firmar 
con un certificado revocado). Como resultado, se dispondrá de 
una taxonomía completa de ataques a la firma electrónica, 
posibilitando la clasificación y estudio de cualquier ataque que 
afecte a su fiabilidad como evidencia de no repudio. 
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Abstract—En este artículo se presenta el diseño y la imple- 
mentación de una solución para el envío de información con 
soporte de firma digital y cifrado desde un dispositivo móvil a 
un servidor web. El artículo no sólo introduce los fundamentos 
técnicos de las herramientas y tecnologías utilizadas, sinó que 
también presenta el estado del arte de este tipo de tecnologías 
y las características, ventajas y desventajas de otras soluciones 
y en especial de la solución presentada en este trabajo de 
investigación. Finalmente, se analiza el protocolo implementado 
haciendo especial referencia a las propiedades de seguridad 
introducidas en él y a las técnicas aplicadas para conseguir este 
fin. 


I. INTRODUCCIÓN 


El acceso a Internet a través de dispositivos móviles es 
cada vez más utilizado. Distintos estudios indican que en los 
próximos años casi la mitad de los usuarios se conectarán a 
Internet a través de dispositivos móviles. 

El sector de las telecomunicaciones se encamina progre- 
sivamente a la convergencia de las redes fija y móvil. Los 
fabricantes de teléfonos están desarrollando terminales con 
acceso a Internet, correo electrónico, etc. y las operadoras 
lanzan al mercado tarifas de telefonía móvil e Internet a 
precios cada vez más competitivos. 

Actualmente ya existen multitud de dispositivos móviles 
que disponen de una interfaz de acceso Wi-Fi con la que es 
posible acceder a Internet a un precio más económico. El único 
inconveniente es la necesidad de un punto de acceso, por lo 
que se deja de ser completamente móvil. 

En un futuro no muy lejano se espera disponer de una 
conexión móvil para acceder a Internet, es decir, se podrá 
acceder desde el lugar que sea, desde el dispositivo que sea y 
en el momento que sea preciso. 

Todos estos avances provocan la necesidad y la demanda 
de aplicaciones y servicios en terminales móviles como por 
ejemplo: consultar el correo electrónico, consultar notícias, 
visualizar mapas y callejeros, enviar imágenes y vídeos, etc. 

En este artículo presentamos el diseño de una aplicación 
para plataformas móviles, concretamente una aplicación para 
el envío de texto e imágenes desde un dispositivo móvil a un 
servidor web pero con el valor añadido de que los mensajes 
son enviados cifrados y firmados digitalmente. Con este fin 
hemos definido un protocolo de comunicación entre terminal 
y servidor donde la seguridad juega un papel muy importante. 
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En realidad se han desarrollado dos aplicaciones, una para 
el emisor (dispositivo móvil) y una para el receptor (servidor 
web). Para el desarrollo de la aplicación del emisor se ha 
utilizado la novedosa plataforma de programación de software 
para dispositivos móviles Android desarrollada primero por 
Google y luego por la Open Handset Alliance [9], mientras 
que para el receptor se ha utilizado el servidor web Tomcat 
con soporte a Java servlets y JSPs [3]. La gran ventaja de 
esta configuración es poder utilizar el mismo lenguaje de 
programación (Java) en ambas aplicaciones (emisor y recep- 
tor), lo cuál facilita enormemente el desarrollo y el correcto 
funcionamiento de las operaciones de cifrado y descifrado de 
datos y de firma y verificación de firma digital. 


A. Seguridad 


Uno de los principales objetivos del proyecto ha sido 
construir un protocolo que introdujera seguridad en la co- 
municación emisor-receptor. En el extremo del emisor, el 
protocolo consiste en: construir el mensaje a enviar, firmarlo 
digitalmente utilizando técnicas de criptografía asimétrica y 
funciones resumen (hash), cifrarlo utilizando técnicas de crip- 
tografía simétrica, comprimirlo para reducir el tráfico de red y 
enviarlo. En cuanto al extremo del receptor, el protocolo es el 
siguiente: descomprimir el mensaje recibido, descifrarlo uti- 
lizando técnicas de criptografía simétrica, verificar la validez 
de los certificados digitales utilizados y verificar la firma 
digital mediante técnicas de criptografía asimétrica y funciones 
resumen, enviar una evidencia de recepción del mensaje al 
emisor a través de correo electrónico y tratar el mensaje. 
Mediante esta implementación se ha dotado al protocolo de 
las propiedades de integridad, confidencialidad, autenticidad, 
no repudio de origen y no repudio de recepción. Para lograrlo, 
también se ha desarrollado una infraestructura de clave pública 
(PKD (112], [13)), es decir, un sistema para la gestión de 
certificados digitales y aplicaciones de firma digital. 


B. Aplicación del terminal móvil 


Es importante tener en cuenta que el desarrollo de aplica- 
ciones para dispositivos móviles resulta más complicado que 
el desarrollo tradicional de aplicaciones web o de escritorio ya 
que, está limitado tanto en la capacidad de recursos hardware 
(principalmente de memoria y de procesador) como en el 


uso de librerías y funcionalidades propias del lenguaje de 
programación para dispositivos móviles utilizado. 

Otro aspecto importante del trabajo que presentamos aquí 
ha sido el relativo al rendimiento de la aplicación del emisor 
(dispositivo móvil), especialmente por la carga que suponen 
las operaciones criptográficas. Como durante todo el desarrollo 
del proyecto se ha trabajado sobre un emulador, se ha intentado 
dar respuesta a la pregunta ¿soportaría un terminal real, 
con sus limitaciones hardware, la carga generada por estas 
operaciones criptográficas?. La conclusión de la investigación 
llevada a cabo es que no es posible juzgar el rendimiento 
de la aplicación en base al emulador, ya que a pesar de 
poder hacer estimaciones en referencia a la CPU, no existe 
emulación del bus de memoria, no existe aceleración gráfica 
por hardware, etc. Por tanto, la única manera de conocer el 
comportamiento de la aplicación realmente es ejecutándola 
sobre un dispositivo real. Apuntar que, de forma definitiva, 
la aplicación desarrollada se ha trasladado del emulador al 
terminal físico y el rendimiento ha resultado ser satisfactorio, 
teniendo en cuenta la carga operacional requerida. 

Finalmente, decir que modificando mínimamente la apli- 
cación del emisor y adaptando la aplicación del receptor 
para realizar el correspondiente tratamiento de los mensajes 
recibidos, este proyecto es válido para numerosas aplicaciones. 


II. ENTORNO DE DESARROLLO 


En esta sección se describe el entorno de desarrollo y las 
distintas tecnologías utilizadas en este proyecto. 

Tanto para el desarrollo de la aplicación emisor como de la 
aplicación receptor se ha utilizado: 

+. El sistema operativo GNU-Linux (release 2.6.24-23- 
generic), concretamente la distribución Ubuntu 8.04 - 
Hardy Heron - publicada en abril de 2008. 

La plataforma de desarrollo: Java Standard Edition 6 JDK 
(product version 6, development version 1.6.0). 

El entorno de desarrollo integrado Eclipse que, al estar 
formado por módulos (plugins), ofrece una plataforma 
ligera para componentes de software. De este modo, cada 
usuario puede instalar y activar únicamente los plugins 
que precisa. Para el desarrollo de la aplicación emisor 
se ha utilizado Eclipse junto al plugin ADT (Android 
Development Tools) que incluye una serie de extensiones 
para facilitar la creación, ejecución y depuración de 
aplicaciones Android, mientras que en la aplicación re- 
ceptor, se ha utilizado Eclipse para la implementación 
de los Java servlets de recepción y publicación, y las 
correspondientes clases satélite. 

Para el desarrollo de la aplicación emisor se ha instalado 
el kit de desarrollo Android SDK (Android 1.0 SDK, Release 
1) proporcionado por Google. En este kit se encuentran todas 
las herramientas necesarias (entorno de depuración, librerías, 
emulador de terminal móvil, documentación, tutoriales, código 
de ejemplo, etc.) para poder desarrollar aplicaciones para la 
plataforma Android [11]. Android es una solución completa de 
software de código libre para teléfonos y dispositivos móviles 
constituida básicamente por un sistema operativo, un conjunto 
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de librerías de bajo nivel como SQLite para la persistencia 
de datos, OpenGL ES para la gestión de gráficos 3D, Webkit 
como motor de rendeado HTML, etc., y un conjunto inicial de 
aplicaciones orientadas al usuario final. Las aplicaciones An- 
droid están programadas en Java pero no corren sobre J2ME, 
sino sobre Dalvik [7], una máquina virtual Java optimizada 
para dispositivos empotrados desarrollada expresamente por 
Google. 

Por otro lado, comentar que la aplicación receptor se ejecuta 
sobre un servidor web, concretamente se ha instalado el 
servidor web con soporte de servlets y JSPs Apache Tomcat 
(versión 6.0.18). 

A continuación se describen brevemente las herramientas, 
APls y algoritmos utilizados en la implementación de las 
aplicaciones emisor y receptor: 


JDOM [4]: API que se ha utilizado para el acceso, la 
manipulación y la salida de datos XML. 

Clase Base64: clase Java que se ha utilizado para la 
codificación y decodificación de información en base 64. 
Antes de poder embeber una imagen, una firma digital o 
un contenido cifrado en un fichero XML debe codificarse 
en base 64. 

RSA [1]: sistema criptográfico de clave pública que se 
ha utilizado para implementar la envoltura digital! y las 
operaciones de firma digital. 

AES [14]: esquema de cifrado por bloques utilizado para 
el cifrado de los datos. Concretamente, se ha utilizado en 
modo de cadena de cifrado de bloque (CBC). 
java.util.zip: paquete que permite la compresión y des- 
compresión de ficheros. Para paliar la expansión pro- 
ducida por las distintas codificaciones en base 64, se 
decidió comprimir el fichero a enviar. 


Finalmente, para la gestión de los diferentes keystores?, de 
los pares de claves y los certificados digitales se han utilizado 
las herramientas Keytool TUI [5] y OpenSSL [10]. 


TIT. ESTADO DEL ARTE 


Como veremos a continuación, actualmente ya existen di- 
versas soluciones de firma electrónica y cifrado sobre disposi- 
tivos móviles. La firma electrónica y el cifrado móvil pueden 
aportar autenticidad, integridad, no repudio y confidencialidad 
si se utilizan en el entorno adecuado de un protocolo de 
comunicación. 

En la telefonía comercial se ofrece un servicio de firma 
electrónica móvil ([8], [17]), que permite autenticar al usuario 
y firmar transacciones y documentos digitales de todo tipo 
mediante el móvil. Las desventajas de este servicio son su 
elevado coste y que de momento sólo se ofrece a clientes 
empresa. 


l Envoltura digital: técnica utilizada en la negociación de claves simétricas 
mediante criptografía asimétrica. Consiste en utilizar un método seguro para 
compartir claves (por ejemplo RSA) y un método rápido para cifrar los datos 
(por ejemplo AES). 

2Keystore: un almacén de claves es un archivo de base de datos de claves 
que contiene tanto las claves públicas como las privadas. 


Por otro lado, la empresa tailandesa CryptoGraf [2] ofrece 
un producto que permite el envío y la recepción de mensajes 
SMS y MMS cifrados y firmados digitalmente entre usuarios 
de la aplicación. La desventaja de este producto es el aumento 
de tamaño de los mensajes (overhead) debido al cifrado y 
a la firma digital, que provoca que éstos deban fraccionarse 
y enviarse por partes. Por ejemplo, en el caso de enviar un 
mensaje SMS cifrado y firmado digitalmente, el overhead es 
de como mínimo tres mensajes. 

Otra empresa, en este caso la española Lleida.net [6] ofrece 
un servicio de notificaciones certificadas vía SMS que se 
utiliza para notificar multas o sanciones como sustituto de las 
cartas certificadas o los burofaxes. Las principales ventajas 
de este servicio son su bajo coste, la rapidez del proceso de 
certificación y el ahorro de papel y tinta. La desventaja es que 
de momento sólo permite el envío de SMSs. 

En este proyecto se han mantenido las ventajas de las 
soluciones existentes y se han eliminado sus desventajas. Una 
de las principales ventajas de la solución presentada aquí es su 
versatilidad, ya que realizando una serie de pequeñas modifi- 
caciones pueden implementarse diversos escenarios. Como la 
conexión entre emisor y recepetor es a través de internet, puede 
enviarse prácticamente cualquier tipo de contenido digital. 
Por ejemplo: el usuario se podría descargar un documento, 
firmarlo digitalmente y enviarlo al receptor. Tampoco resultaría 
complicado incluir una autoridad selladora de tiempo para 
tener constancia ante terceros del momento en que se realiza 
la firma digital. 

La implementación final de este proyecto se ha orientado 
a la publicación móvil segura de imágenes. Existen diversos 
escenarios donde podría resultar útil, como por ejemplo en 
la gestión de las infracciones de tráfico o de aparcamiento. 
Los agentes al detectar una infracción, como por ejemplo un 
coche mal aparcado, procederían a tomar una fotografía de la 
misma y la envíarían al receptor junto a una serie de datos, 
como su número de agente, el número de matrícula del coche 
implicado, y la descripción de la infracción. 

Actualmente, en la web 2.0, existen numerosas soluciones 
de publicación de imágenes a través de dispositivos móviles 
pero no con soporte de cifrado y firma digital como se ofrece 
en este proyecto. En algunos casos la publicación de imágenes 
se lleva a cabo enviando la imagen por correo electrónico a una 
dirección única de carga. En el trabajo que hemos desarrollado 
aquí se realiza mediante una conexión directa con el receptor, 
utilizando el método POST del protocolo HTTP. 


IV. SOLUCIÓN IMPLEMENTADA 


Con el fin de realizar una descripción de la forma más clara 
y concreta posible, en esta sección se describe la solución 
diseñada como caso específico de implementación del proto- 
colo genérico de comunicaciones seguras entre terminal móvil 
y servidor desarrollado. 


A. Nuestras playas online 


En este caso concreto hemos desarrollado una aplicación 
que hemos llamado Nuestras playas online. En esta aplicación 
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los emisores, que pueden ser los propios vigilantes de la playa, 
van enviando periódicamente fotos de la playa en la que se 
encuentran junto a su información de estado, concretamente 
la bandera, la temperatura, el viento, si hay medusas u otros 
animales que podrían ser considerados peligrosos para los 
bañistas, el oleaje, si hay corriente, si hay posidonia y la 
cantidad de gente. 

El receptor (que aquí sería el servidor de la autoridad 
competente en costas), al recibir un mensaje lo trata y publica 
la información correspondiente en una página web, de modo 
que cualquier ciudadano pueda consultar el estado de las 
playas antes de salir de casa. 


B. Protocolo de transmisión 


1) Notación: En la tabla 1 especificamos el significado de 
los elementos utilizados durante la emisión y recepción de 
la información. En esta tabla, el símbolo ”+” se utiliza para 
indicar la concatenación de los elementos implicados. 


Mia Mensaje XML que contiene la imagen y la información que se 
pretende enviar 
AO Almacén de claves 


.. Clave privada del emisor 
.. Clave pública del emisor 
RARA Clave privada del receptor 
OA Clave pública del receptor 
Firma digital 
res Fecha actual 
PS Hash (resumen digital) del mensaje M 
AAA Mensaje M firmado: M + F + Fa 
EE Vector de inicialización para el modo CBC del algoritmo AES 
AAA Clave secreta para utilizar en el algoritmo AES 
CX(IV, SK, MF) Cifrar el mensaje MF utilizando el vector de inicialización 1V y 
la clave secreta SK 


PUR(SK) ...... Cifrar la clave secreta SK mediante la clave pública del receptor 
PUr 

Merry Mensaje M firmado y cifrado: IV + CX(IV,SK,MF) + PUR (SK) 

CM) Faas Compresión del mensaje M 

Mc Mensaje M firmado, cifrado y comprimido 

D(MC) oocoo.oo.o. Descompresión del mensaje comprimido MC 

PRR(MX) ...... Recuperar la clave secreta SK del mensaje firmado y cifrado MX 


mediante la clave privada del receptor PRr 
DX (IV, SK, MX) Descifrar el mensaje firmado y cifrado MX utilizando el vector de 
inicialización 1V y la clave secreta SK 


FE(ME) ........ Recuperar fecha de firma digital del mensaje firmado MF 
CURRAR Certificado de clave pública del emisor 

VACÉM) common Verificar si el certificado C era válido al firmar el mensaje M 
WC Cadarzs Verificar si el certificado C1 era válido al firmar el certificado Ca 


VF (PU, F, M) . Verificación de la firma digital 
ENV (NRR, M) .. Enviar no repudio de recepción del mensaje M 


Tabla 1. Descripción de los elementos implicados en el protocolo. 
AMARA NR Crear mensaje 
2 PRE e Auris . Recuperar clave privada del emisor 


3.F <= PRe(H(M))... . Firma digital del mensaje 
4, MP <= M4+TF 4 Fa. ... Construir mensaje firmado 
A A Generar clave secreta 


O E Generar vector de inicialización 
(BUE: Rs AA Recuperar clave pública del receptor 
8S.MX = IV + CX(IV,SK,MF) + PUr(SK) Cifrar mensaje firmado 
BELMS ETA orar rre Comprimir mensaje cifrado 
DIAM] Enviar mensaje comprimido 
Tabla 2. Pasos del protocolo de transmisión realizados por la aplicación 


emisor. 


2) Descripción: 


Emisión: En la tabla 2 enumeramos y describimos cada 


una de las operaciones que realiza la aplicación instalada en 
el dispositivo de comunicación móvil. El objetivo principal de 
la aplicación emisor es enviar una imagen junto a unos deter- 
minados datos a la aplicación receptor, con la peculiaridad de 
que la información enviada está firmada digitalmente, cifrada 
y comprimida. 


A continuación se describen detalladamente los pasos del 


protocolo realizados en la aplicación emisor: 


. Paso 1: Construcción del fichero XML a enviar (M): 


— Seleccionar la imagen a publicar. 
— Embeber la imagen codificada en base 64 en un 
fichero XML temporal: tmp.xml (M). 
— Añadir el alias del usuario, la dirección de correo 
electrónico donde recibir la evidencia de recepción 
y, en el caso concreto de la aplicación desarrollada, 
se añaden al fichero tmp.xml (M) el resto de los datos, 
como por ejemplo: la isla, la playa, la bandera, etc. 
e Pasos 2, 3 y 4: Firmar el fichero tmp.xml (M) construido, 
obteniendo el fichero tmpFirmado.xml (MF): 


Recuperar la clave privada del emisor (PRg) del 

almacén de claves (AC). 

Firmar el fichero tmp.xml construido utilizando la 

clave privada del emisor (PR pg). 

Añadir la firma en base 64 al contenido del fichero 

tmp.xml (M). 

Añadir la fecha actual (F,) al contenido del fichero 

tmp .xml (M) para dejar constancia de cuándo ha sido 

firmado. 

Almacenar el fichero resultante como 

mado .xml (MF). 

Si ocurre un error durante este proceso (por ejemplo 

si la contraseña para acceder al almacén de claves es 

incorrecta) se construye un documento XML de error 

con el alias, el error y la fecha actual (M = alias 

+ error + fecha actual), que es enviado en 

lugar del fichero XML construido anteriormente (se 

denomina tmpFirmado.error). De este modo el re- 

ceptor puede detectar si se producen intentos fallidos 

de acceso a la clave privada de un determinado 

emisor. 

e. Pasos 5, 6,7 y 8: Cifrar el fichero tmpFirmado.xml (MF) 
obteniendo el fichero tmpCifrado.xml (MX): 

Generar clave secreta (SK) de un sólo uso de 256 

bits (Unlimited Strength Cryptography [16]). 

Generar el vector de inicialización (IV), para poder 

utilizar el modo CBC del algoritmo AES. 

Cifrar el fichero tmpFirmado.xml (MF) utilizando el 

algoritmo AES con la clave secreta (SK) y el vector 

de inicialización (IV) generados. 

Crear el fichero tmpCifrado.xml (MX) con el vector 

de inicialización (IV) concatenado al contenido del 

fichero tmpFirmado.xml (MF) cifrado. 


impFir- 
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— Recuperar la clave pública del receptor (PU) de su 
certificado digital que se encuentra almacenado en el 
almacén de claves (AC). 
Cifrar la clave secreta (SK) con la clave pública 
del receptor (PU), de forma que sólo éste podrá 
descifrarla mediante su clave privada. 
Añadir la clave secreta (SK) cifrada con la clave 
pública del receptor (PU) al fichero tmpCifrado .xml 
(MX). 
Paso 9: Comprimir el fichero tmpCifrado.xml (MX) para 
optimizar el envío y paliar el incremento de tamaño 
producido por las distintas codificaciones en base 64 
realizadas, obteniendo el fichero tmpCifrado.gzip (MC). 
Paso 10: Enviar el fichero tmpCifrado.gzip (MC) es- 
tableciendo una conexión con el servlet de recepción de 
la aplicación receptor utilizando el método POST del 
protocolo HTTP. 

Recepción: En la tabla 3 expresamos de forma esquemática 
cada una de las operaciones que realiza el servidor en la 
recepción de los mensajes. 


MARA AA Recepción del mensaje comprimido 

2,MX <= D(MC). . Descomprimir, obteniendo el mensaje cifrado 
A A AO Recuperar vector de inicialización 

4.PRR E ACl...... . Recuperar clave privada del receptor 


SK <= PRr (MX) ... 
MF << DX(IV,SK,MX) 


Recuperar clave secreta 
Descifrar, obteniendo mensaje firmado 


7. (Fa —= Tm) < FE(MEF) < Fa?.. Verificar validez del periodo margen 

8 rara Recuperar certificado digital del emisor 

DIOSES asco ca RETA Verificar validez del certificado digital del 
emisor en el momento de firmar el mensaje 

10. BS Meca Recuperar certificado digital de la autoridad 


certificadora 

- Verificar validez del certificado digital de la au- 
toridad certificadora en el momento de firmar 
el certificado de usuario 

. Recuperar la clave pública del emisor 

. Recuperar la firma digital del mensaje firmado 

. Recuperar el mensaje original del mensaje fir- 
mado 

NIDOS MO ara Verificar la firma digital 


16. ENV(NRR. M) ...ooooommmmcorcoran os Enviar evidencia de recepción 
Ei Missast ASA Tratamiento del mensaje 
Tabla 3. Pasos del protocolo de transmisión realizados por la aplicación 


receptor. 


La aplicación receptor realiza dos funciones bien diferenci- 

adas: 

+. Recibir y publicar los mensajes enviados desde las 
aplicaciones emisoras (dispositivos móviles) a través 
de una interfaz HTTP POST implementada mediante 
un servlet. 

+ Proporcionar acceso vía web a la información publi- 
cada a través de un conjunto de páginas HTML y un 
servlet que carga la información desde el fichero XML 
correspondiente. 

A continuación se describen detalladamente los pasos del 

protocolo realizados en la aplicación receptor: 

. Paso 1: Recepción del fichero tmpCifrado.gzip (MC). 
Como pueden llegar múltiples archivos simultáneamente 
es necesario identificarlos unívocamente por lo que el 
fichero recibido es renombrado como idUnico.gzip. 


+. Paso 2: Descomprimir el fichero idUnico.gzip (MC) obte- 
niendo el fichero idUnicoCifrado.xml (MX). 

Pasos 3, 4, 5 y 6: Descifrado del fichero idUnico- 
Cifrado. .xml (MX): 

Recuperar el vector de inicialización (IV) del fichero 
idUnicoCifrado.xml. 

Recuperar la clave privada del receptor (PR) del 
almacén de claves (AC). 

Extraer la clave secreta (SK) del fichero idUnico- 
Cifrado.xml utilizando la clave privada del receptor 
(PRA) (sólo éste puede decifrarla). 

Descifrar el contenido del fichero i¿dUnicoCi- 
frado.xml mediante el vector de inicialización (IV) 
y la correspondiente clave secreta (SK), obteniendo 
el fichero idUnicoFirmado.xml (MF). 


Paso 7*: Comprobar si la fecha de firma no es anterior al 
periodo margen (T,,) ni posterior a la fecha actual (F,): 


— Utilizar la fecha de firma incluida en el fichero 
idUnicoFirmado.xml (MF) y la fecha actual (F¿). 
Pasos 8 y 9: Comprobar la validez del certificado de 
usuario en el momento de realizar la firma digital: 


— Recuperar el certificado del usuario emisor (C ¿) del 
almacén de claves (AC). 

— Comprobar si el certificado era válido en el momento 
de firmar el fichero idUnicoFirmado.xml (MF) (éste 
contiene la fecha de firma). 


Pasos 10 y 11: Comprobar la validez del certificado de 
la autoridad certificadora en el momento de firmar el 
certificado de usuario: 


Recuperar el certificado del usuario emisor (C g) del 
almacén de claves (AC). 
Recuperar la fecha de creación del certificado de 
usuario del emisor (Cp). 
Recuperar el certificado de la autoridad certificadora 
(Ca). 
Comprobar si el certificado de la autoridad certifi- 
cadora (C 4) era válido en el momento de firmar el 
certificado de usuario del emisor (Cp). 
+. Pasos 12, 13, 14 y 15: Verificar la firma digital del fichero 
idUnicoFirmado.xml (MF): 
— Recuperar la clave pública del emisor (PUpg) del 
almacén de claves (AC). 
— Recuperar la firma del fichero (F) idUnicoFir- 
mado. xml. 
— Recuperar el texto que fue firmado (M) del fichero 
idUnicoFirmado.xml. 


3Según el tipo de aplicación final, podría ser interesante disponer de un 
servicio de sellado temporal, es decir, en lugar de enviar directamente el 
fichero al receptor se enviaría antes a una autoridad de sellado de tiempo que 
incluiría un sello temporal en el fichero en cuestión. De este modo se tendría 
constancia ante terceros del momento en que se realizó la firma digital. En 
la implementación actual lo que se ha hecho es incluir la fecha en que se 
realizó la firma digital en el fichero enviado y en el receptor se verifica 
que como máximo la firma tenga una antigúedad de Tmargen y no sea 
posterior a la fecha actual, evitando así la posibilidad de recibir una fecha 
falsa, bastante anterior a la real o posterior a la fecha actual, y eludir por 
tanto la manipulación de la comprobación de la validez de los certificados. 
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— Verificar la firma digital. 

— Si la verificación de firma es correcta, crear el 
fichero idUnico.xml (M) que contiene únicamente el 
contenido que el emisor pretendía enviar al receptor. 

— Si la verificación de firma es incorrecta se registra 
en el fichero de logging. 

+. Pasos 16 y 17: Si la verificación de la firma digital ha 
sido correcta, tratar la información recibida contenida en 
el fichero idUnico.xml (M) y enviar al emisor la corres- 
pondiente evidencia de recepción (NRR) del mensaje: 

— Extraer la imagen del fichero idUnico.xml y almace- 

narla en la ubicación correspondiente. 

Extraer el alias, la dirección de correo electrónico, la 
isla, la playa, la bandera, etc. del fichero ¡dUnico xml 
(M) y realizar las correspondientes tareas de publi- 
cación. 

Enviar a la dirección de correo electrónico solicitada 
por el emisor una evidencia de recepción (NRR) (no 
repudio de recepción). 


V, ANÁLISIS INFORMAL DE LA SEGURIDAD DEL 
PROTOCOLO 


Para que una transacción online se considere segura debe 
cumplir las propiedades de integridad, confidencialidad, no 
repudio en origen, no repudio de recepción y autenticación. 
En este proyecto se han utilizado técnicas de criptografía 
simétrica para el cifrado de los mensajes enviados del emisor 
al receptor. Concretamente, se ha utilizado el esquema de 
cifrado por bloques AES con una clave secreta de 256 bits. 
La criptografía simétrica dota al protocolo de la propiedad de 
condidencialidad. Para la implementación de la firma digital 
y el cifrado de la clave secreta, se han utilizado técnicas de 
criptografía asimétrica. Concretamente el sistema criptográfico 
de clave pública RSA con claves de 1024 bits. La criptografía 
asimétrica mediante la implementación de la firma digital dota 
al protocolo de las propiedades de integridad, confidencialidad 
y no repudio en origen. En el caso del dipositivo móvil, el 
par de claves es generado externamente por un operador de 
registro al dar de alta a un nuevo usuario y es almacenado en 
un almacén de claves de tipo BKS [15] junto al conjunto de 
ficheros que conforman la aplicación Android. En Android, 
por defecto, todos los datos asociados a una aplicación son 
privados para esa aplicación por lo que, en principio, la única 
forma de acceder al fichero que implementa el almacén de 
claves para intentar comprometer la seguridad del sistema sería 
accediendo al terminal como usuario root. 

Finalmente, se ha implementado un mecanismo para dotar 
al protocolo de la propiedad de no repudio de recepción. Este 
mecanismo consiste en el envío (mediante correo electrónico) 
por parte del receptor al emisor de una notificación de re- 
cepción del mensaje. Por tanto, también queda constancia de 
la fecha de recepción del mensaje. 


VI. RENDIMIENTO DEL DISPOSITIVO MÓVIL REAL 


Para analizar el rendimiento del dipositivo móvil real se han 
realizado distintas ejecuciones de la aplicación implementada 


capturando el tiempo de ejecución de las distintas operaciones 
realizadas (componer el mensaje, firmar digitalmente, cifrar, 
comprimir y enviar). Los resultados obtenidos se pueden 
observar en la tabla 4. 


Tamaño ficheros (KB) - Tiempo Operaciones (ms) 

Imagen Crear M M Firmar MF  Cifrar MX Comp. MC Enviar Total 
99,3 2329 134,6 6277 134,9 5068 182,5 337 140,7 1151 15162 
199,8 1894 270,4 9754 270,7 9373 366 798 282,3 867 25686 

270,1 6409 365,3 11715 365,6 12295 494,2 881 381 1510 32810 
368,1 8788 197,7 — 14352 198 16834 673,1 1247 519 1464 12685 
165,5 10507 629,3 18642 629,6 20463 850,8 1839 656 1639 53090 
517.6 13074 699.6 20072 699,9 23493 945,8 1627 729,3 2260 60526 ] 
Tabla 4. Tiempo consumido por dispositivo móvil real para realizar las 


distintas operaciones sobre ficheros de distintos tamaños. 


Como se puede observar, las operaciones criptográficas 
consumen la mayor parte del tiempo, alrededor del 70% del 
mismo. La operación de composición del mensaje consume 
aproximadamente una quinta parte del tiempo total, debido 
esencialmente a la codificación en base 64 de la imagen, mien- 
tras que las operaciones de compresión y de envío consumen 
una parte muy reducida del tiempo. 

Dado que los algoritmos de compresión se basan en la 
eliminación de la redundancia de datos se ha verificado que 
resulta más eficiente realizar antes la operación de compresión 
que la de cifrado, hecho que se tendrá en cuenta en futuras 
versiones del protocolo. 


VII. CONCLUSIONES Y TRABAJOS FUTUROS 


En este artículo se presenta una posible solución al problema 
de enviar información de forma segura desde un dispositivo 
móvil a un servidor web. Para lograrlo se han tenido que tomar 
una serie de decisiones y ha sido necesario el dominio de nu- 
merosas tecnologías, algoritmos criptográficos y herramientas 
distintas. 

Durante el proceso de investigación se ha experimentado 
con numerosas plataformas de desarrollo para dispositivos 
móviles pero tarde o temprano siempre aparecía alguna limi- 
tación grave, como por ejemplo la imposibilidad de realizar 
todas las operaciones criptográficas requeridas en esta im- 
plementación, la imposibilidad de manipular ficheros XML, 
etc. Finalmente la plataforma Android ha permitido la imple- 
mentación con las características deseadas. 

Por otro lado, actualmente las principales barreras con las 
que se encuentran las soluciones como la presentada son el 
elevado coste de las comunicaciones móviles y los problemas 
de rendimiento de los terminales, pero parece ser que en 
un futuro no muy lejano dejarán de serlo. Actualmente, una 
solución para reducir el coste de la conexión a Internet consiste 
en conectarse a través de la interfaz Wi-Fi del terminal. 

Entre las posibles mejoras que preveemos en el protocolo y 
la aplicación desarrollada se encuentran los siguientes trabajos 
futuros: 


. Mejorar la infraestructura de clave pública (PKD), de 
forma que el usuario pueda generar su par de claves desde 


9% 


la aplicación emisor y enviar la correspondiente solicitud 
de firma del certificado. 

Modificar el protocolo de transmisión para añadir la 
propiedad de equidad a las propiedades de seguridad ya 
existentes. 

Dado que se ha verificado que resulta más eficiente 
realizar primero la operación de compresión que la de 
cifrado, intercambiar el orden de estas operaciones en el 
protocolo. 

Determinar el tamaño de las claves simétricas y 
asimétricas que ofrezcan la relación rendimiento-nivel de 
seguridad más adecuada. 

Ubicar el almacén de claves de la aplicación emisor en la 
tarjeta SIM para aumentar el nivel de seguridad y reducir 
el tiempo de cálculo. 
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Máxima Seguridad para Firmas Digitales con 


Verificación Distribuida 


Javier Herranz!, Alexandre Ruiz!, Germán Sáez! 


Abstract—Una de las opciones para proteger el nivel de 
anonimato o privacidad de un firmante es construir firmas 
digitales con verificación distribuida: se requiere la colaboración 
de un subconjunto autorizado de usuarios para verificar la 
(in)validez de una firma. En RECSI'08, se propuso un esquema 
de este tipo, pero que no alcanzaba el máximo nivel de seguridad. 
En este trabajo proponemos el primer esquema de firma digital 
con verificación distribuida que consigue seguridad máxima, 
en términos de infalsificabilidad y privacidad. Demostramos 
formalmente estas dos propiedades por reducción a problemas 
computacionales estándar, en el modelo del oráculo aleatorio. 

Index Terms—Firma digital, compartición de secretos, modelo 
del oráculo aleatorio, indistinguibilidad 


I. INTRODUCCIÓN 


En algunas situaciones la propiedad de verificación univer- 
sal en una firma digital puede ser no deseable, si el firmante 
desea un cierto nivel de anonimato o de privacidad. Una posi- 
ble solución a este problema consiste en exigir la colaboración 
de varios usuarios para que el protocolo de verificación se 
pueda ejecutar correctamente. Este tipo de esquemas recibe 
el nombre de esquemas de firma con verificación distribuida, 
que pueden aplicarse en situaciones reales como subastas o 
votaciones electrónicas. 

En [6], se definen las propiedades de seguridad (infalsifica- 
bilidad y privacidad) que debe satisfacer un esquema de firma 
con verificación distribuida. También se propone un esquema 
concreto, pero dicho esquema no alcanza el máximo nivel de 
seguridad respecto a la propiedad de privacidad. 

En este trabajo proponemos el primer esquema de firma con 
verificación distribuida que satisface las máximas propiedades 
de seguridad. En particular, el esquema es seguro incluso 
ante atacantes que conocen las claves secretas de todos los 
participantes (excluido el participante que se está atacando). 
Conviene remarcar que esta propiedad (conocida como insider 
security, en inglés) no es en absoluto fácil de conseguir: 
incluso construcciones genéricas obtenidas al combinar un 
esquema de firma con un esquema de cifrado con descifrado 
distribuido no satisfacen este nivel máximo de seguridad. 
La definición detallada de estas propiedades de seguridad 
se puede encontrar en la Sección III. El diseño del nuevo 
esquema, que se presenta en la Sección IV, sigue las ideas del 
esquema de cifrado distribuido de Shoup y Gennaro [9]. En la 
Sección V, demostraremos formalmente las dos propiedades 
de seguridad, en el modelo del oráculo aleatorio, por reducción 
a dos problemas estándar: el problema del logaritmo discreto, 
y el problema Computacional de Diffie-Hellman. 
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II. ESQUEMAS DE FIRMA CON VERIFICACIÓN DISTRIBUIDA 


Un esquema 2 de firma con verificación distribuida consiste 
en cuatro protocolos probabilísticos y de tiempo de ejecución 
polinómico: 

1) fni. La entrada es un parámetro de seguridad A. Las 

salidas son unos parámetros públicos params utilizados 
en todo el esquema. 


Y.Ini(14) = params 


2) Gen_Cla. Este protocolo utiliza dos algoritmos. El 
primero corresponde al firmante A que obtendrá un par 
de claves (ska,pka), donde ska es la clave privada 
para firmar y pka es la correspondiente clave pública. 
El segundo algoritmo corresponde a un conjunto B de 
n verificadores, que tiene asociada una estructura de 
acceso (monótona creciente) Pg C 28, que contiene 
los subconjuntos autorizados a verificar. Estos usuarios 
obtendrán cierta información privada (sk;Ljeg que va 
a ser usada más tarde en el proceso de verificación 
distribuida, y cierto valor público pkg común para el 
conjunto B. El proceso de generación de claves para 
el colectivo B puede ser ejecutado por una tercera 
autoridad de confianza o de manera conjunta por ellos 
mismos, usando técnicas conocidas [3]. 


.GC(params, A, individual”) = (ska,pka) 
.GC(params, B,T y, “colectivo”) = ((sk;J;jen, pkg) 


3) Firm. Este algoritmo es ejecutado por el firmante A; 
toma como entrada un mensaje m, su clave privada 
ska y la clave pública asociada a un grupo B de 
verificadores, y da como salida una firma 0(m) del 


mensaje. 
.Firm(params,m, pkg, ska) =0(m) 


4) Ver_Dist. Dado B € I'g un subconjunto autorizado 
de verificadores, este protocolo toma como entrada un 
mensaje m, una firma 0, la clave pública pka1 y los 
fragmentos sk; de los usuarios j € B. La salida será 
1 si O(m) es una firma válida de m y 0 en el caso 


contrario. 
Y Ver(params,m,0,pka, B,fskiljen) =160 


Hay que remarcar que el primer y segundo protocolos se 
ejecutan sólo una vez. Los otros dos protocolos, i.e. el proceso 
de firma y de verificación, se ejecutan tantas veces como los 
participantes quieran firmar o verificar. 


TII. MODELO DE SEGURIDAD 


Las propiedades de seguridad que un esquema de firma 
con verificación distribuida deberá satisfacer son las de in- 
falsificabilidad y privacidad. Nuestro objetivo es considerar 
las nociones de seguridad más fuertes posibles. Por esta 
razón al adversario se le permite hacer peticiones de firma 
y verificación para diferentes usuarios, mensajes y firmas. 

Además se le permite corromper al mayor número de 
participantes posibles (con la excepción de los usuarios que 
sean objetivo de su ataque en cada caso). En particular, 
la infalsificabilidad se alcanza incluso cuando el adversario 
conoce toda la información secreta de todos los participantes 
con la excepción del firmante que quiere atacar. Por otra parte, 
la privacidad se consigue incluso en el caso que el adversario 
conozca las claves secretas de todos los posibles firmantes y 
de un subconjunto no autorizado de verificadores. Este nivel 
de seguridad recibe en inglés el nombre de insider security. 


A. Infalsificabilidad 


La infalsificabilidad existencial contra ataques de mensaje 
escogido [5] requiere que cualquier atacante debe tener pro- 
babilidad despreciable ! de falsificar una firma válida de un 
usuario (del cual no conoce su clave secreta), incluso si el ata- 
cante puede obtener previamente otros pares (mensaje, firma) 
válidos, para mensajes y conjuntos de verificadores que él 
escoge adaptativamente. 

Esta propiedad se formaliza con el siguiente juego, en el 
que dado un parámetro de seguridad A un retador externo reta 
a un atacante Finf para que intente falsificar una firma válida 
nueva: 


1) El retador ejecuta params — Y.Ini(14) y da todos los 
valores obtenidos junto con una estructura de acceso I' 


a FiNF- 

2) Finf. escoge un participante  A* para ser 
atacado. El retador ejecuta  (ska+,pkax) E 
.GC(params, A*, individual”), se guarda sk» 


y le da pkax a Fin. 

[Generación de nuevas claves] El atacante puede ejecutar 
(ska, pka) = X.GC(params, A, individual”) para fir- 
mantes A 4 A* de su elección, y también puede ejecutar 
>.GC(params, B,T'g, “colectivo”) = (([sk;)jeg, pkp) 
para conjuntos B de su elección. 

[Peticiones hash] Si la seguridad se considera en el 
modelo del oráculo aleatorio [1], FinfÉ puede hacer 
peticiones al oráculo que modela el comportamiento de 
ciertas funciones hash. 

[Peticiones firma] Finf puede escoger, de manera adapta- 
tiva, tuplas (mg, pkg,) y enviarlas a un oráculo de firma 
para el firmante 4*. Fin obtiene como respuesta las 
firmas 0(m/) — 2.Firm(params, me, pkg,, skax). 


3) 


4) 


5) 


Il Formalmente, decimos que una función f es despreciable (o negligible, en 
inglés) en k si existe un polinomio p(-) y un valor entero positivo ko tal que 
f(k) < 1/p(k) para todo k > ko. Usualmente, se escribe f(k) = negl(k) 
para las funciones f despreciables en k. 
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6) [Falsificación] En un cierto momento, inf publica 
un par (m*,0*) y una clave pkg* para un con- 
junto B* y una estructura de acceso I'g*. El ata- 
cante Fins gana el juego si (m*,0%) 4 (m,,0(mog)), 
para toda firma obtenida durante el ataque, y además 
Y Ver(params,m*,0*, pkaz, B,fskiljen) = 1, para 
algún subconjunto B € T'gs». 

La ventaja de un adversario AinF en romper la infalsifica- 

bilidad de un esquema de firma con verificación distribuida se 
define como 


Vente (A) = Pr[ Fine gana el juego]. 


Definición 1: Un esquema de firma con verificación dis- 
tribuida * es infalsificable si para cualquier adversario Fins 
de tiempo polinómico, el valor Ventf, (A) es despreciable 
con respecto al parámetro de seguridad A. 


B. Privacidad 


Intuitivamente, en una firma digital con verificación dis- 
tribuida se requiere que un atacante que corrompa a un sub- 
conjunto de usuarios no autorizado, no pueda obtener ninguna 
información sobre la (in)validez de las firmas calculadas por 
el usuario A. Para formalizar exactamente qué quiere decir 
“no obtener ninguna información”, se adapta el concepto de 
seguridad semántica (inicialmente introducido para esquemas 
de cifrado y conocido también como indistinguibilidad contra 
ataques de cifrado escogido [4] o IND-CCA). De manera 
informal, dados dos mensajes escogidos por un atacante, y 
una firma válida para uno de estos mensajes, el adversario 
no debe ser capaz de distinguir qué mensaje ha sido firmado 
con probabilidad significativamente mayor que 1/2 (respuesta 
aleatoria). 

Para formalizar esta idea intuitiva, detallamos aquí un juego 
de indistinguibilidad donde un atacante Finp intenta ganar a 
un retador externo: 


1) El retador ejecuta params — Y.Ini(14) y da todos los 
valores obtenidos a Finp. 

Finp escoge un conjunto de verificadores B*, una es- 
tructura de acceso gx C ge y un subconjunto no 
autorizado B £ T'g», cuyos usuarios puede corromper. 
El retador ejecuta el protocolo ((sk;)jjeg»,pkg*) E 
.GC(params, B*, Dg», colectivo”), da al atacante 
Finp los valores pkgw y (sk) y mantiene el resto 
de valores sk, en secreto. 

[Generación de nuevas claves] El atacante puede ejecu- 
tar (ska, pka4) E X.GC(parans, A, individual”) para 
firmantes A de su elección, y también puede ejecutar 
Y.GC(params, B,T y, “colectivo”) = (Lsk;bseg, pkb) 
para parejas (B,T'g) 4 (B*,T'g+) de su elección. 
[Peticiones hash] Si la seguridad se considera en el mo- 
delo del oráculo aleatorio, Finp puede hacer peticiones 
al oráculo que modela el comportamiento de ciertas 
funciones hash. 

[Peticiones verificación] Finp escoge diferentes tuplas 
(m2, 00, pka,) para firmantes Aj de su elección y 
hace peticiones, de manera adaptativa, a un oráculo 


2) 


jeB> 


3) 


4) 


5) 


de verificación para estas firmas, con conjunto de ve- 
rificadores B*. Finp obtiene como respuesta toda la 
información emitida durante la ejecución del protocolo 
Y Ver(params, me, Op, pka,, B*, [sk;hjen»). 

Finp escoge dos mensajes mp, m1 de la misma longitud 
y un firmante A* con claves (ska+,pka+), que Fino 
envía al retador. 

[Desafío] El retador escoge un bit aleatorio b € (0,1) 
y ejecuta 0* — Y.Firm(params, mp, pkgx, ska»). La 
firma resultante 0* se envía a Finp. 

[Más peticiones] Los pasos 4 y 5 son repetidos, con la 
restricción que las tuplas (m,,0*, pka+) no pueden ser 
enviadas al oráculo de verificación, para ¿ = 0, l. 
Finalmente, Finp devuelve un bit d' € (0,1). 


6) 


7) 


8) 


3) 
Decimos que Finp gana el juego si b' = b. La ventaja de 


un tal adversario Finp en romper la privacidad de un esquema 
de firma con verificación distribuida se define como 


Vents,. (A) =/2Pr(0' =0] - 11. 


Definición 2: Un esquema de firma con verificación dis- 
tribuida Y satisface la propiedad de privacidad si para 
cualquier adversario Finp de tiempo polinómico, el valor 
Ventr LA) es despreciable con respecto al parámetro de 
seguridad A. 


TV. EL ESQUEMA PROPUESTO 


En esta sección se describe un esquema específico de 
firma con verificación distribuida. El diseño de este nuevo 
esquema sigue las ideas del esquema de cifrado distribuido 
propuesto por Shoup y Gennaro [9]. Demostraremos que el 
nuevo esquema satisface las nociones máximas de seguridad 
de infalsificabilidad y privacidad. Para simplificar y por falta 
de espacio, consideramos el escenario donde los verificadores 
actúan correctamente en el proceso distribuido. Una modi- 
ficación simple de nuestro esquema, incluyendo pruebas no 
interactivas de conocimiento cero sobre la igualdad de dos 
logaritmos discretos, permite añadir robustez al esquema para 
detectar participantes deshonestos en el proceso distribuido de 
verificación. 

Detallamos a continuación los protocolos que componen 
nuestro esquema de firma con verificación distribuida >, 
para un firmante A y un conjunto B = (f1,...,n) de n 
verificadores. 


1) Ini. E.Ani(12). 
Dado un parámetro de seguridad A € N, se escogen dos 
números primos p y q tales que |q| = A y ql(p—1). Se es- 
coge también un grupo cíclico (+ = (g) de orden primo 
q. Se escoge otro parámetro k« de seguridad, suficiente- 
mente grande (por ejemplo kx = 160) para evitar ataques 
de colisión al esquema. Posteriormente se escogen y 
publican cuatro funciones hash Ho : [0,1)* = (0,1P", 
H¡ :(0,1F* > G, H> :(0,1)* > Z, y H3 :(0,1)* => 
[0, 1). En la demostración de seguridad, supondremos 
que las funciones hash Hp, A, Ha se comportan como 
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2) 


3) 


4) 


Intuitivamente, dada una firma 0(m) 


un oráculo aleatorio [1]. Del protocolo se obtienen los 
valores params = (p, q,G, 9,£, Ho, Hi, Ha, Ha). 
Gen_Cla. Y.GC(paranms, A, “individual”) 
.GC(params, B,Tg, “colectivo”). 
Para el firmante A, la clave secreta es un elemento 
aleatorio xa € Z¿ que guarda de manera privada, 
mientras que la clave pública correspondiente es ya = 
g*A4 mod p. 
Para el colectivo B de n usuarios se publica el valor 
Y8 = y*” para un valor aleatorio 1g € Z¿ que es 
desconocido para los miembros de B. Cada verificador 
j de B recibe un fragmento s; del secreto Ig, corres- 
pondiente a un esquema de compartición de secretos de 
espacio vectorial [2] para la estructura de acceso P'g. 
Es decir, para cada conjunto autorizado B € I'g existen 
coeficientes Di he tales que > je AP sj = Ip. 
Firm. .Firm(params,m, yg, TA). 
Si A quiere firmar un mensaje m € (0, 1)*, ejecuta los 
siguientes pasos: 

a) Escoge un valor aleatorio r € Z¿ y calcula R = 
g” mod p. 
Calcula k 
H3 (k, m). 
Elige valores aleatorios 041,42 € Z¿ y calcula 
Y, =g“* mod p, Y2 = 9”? mod p. 

Calcula g = Hi(c,R,Y,, Ya, Ya, YB) € G, y 
posteriormente R = 7” mod p, Y, = 7% mod p. 
Calcula h = Ha(c, R, 9, R, Y, Ya, Ya, YA, YB). 

f) Calcula s; = 041 — hr mod q. 

Calcula s2 = %2 — h- 14 mod q. 

Devuelve la firma 0(m) = (c, R,R, h, sy, 52). 
Ver_Dist. Y Ver(params,m, 0,Yya, B, [sjhjeB). 

Si los participantes de un subconjunto autorizado B € 
Po quieren cooperar para verificar la firma 0(m) = 
(c, R,R,h,s¡,52) del mensaje m, ejecutan los si- 
guientes pasos. 

a) Cada verificador ¿ € B calcula y = H¡(c, R,g* - 
RP,g%2 - (ya)”,ya, YB) y comprueba entonces 
que la siguiente igualdad se verifica: h 
Ha(c, R, 9, R, g” ci ge Ñ (ya)”, g” -R, YA, yb) 
Si la igualdad no se verifica, j devuelve (¿, 0). 
En caso contrario, j € B devuelve el valor T; = 
R*i mod p. 

Una vez se han recibido valores válidos T,, dife- 

rentes de (;j,0), correspondientes al subconjunto 

autorizado B € Ig, se recupera el valor R*8: 

IM Tr)" = R*% mod p, donde Af? € Zy son los 

¡eB 

cocficienés definidos por el esquema de compar- 

tición de secretos de espacio vectorial. 

Se calcula k = Ho(R, yg, R*8, ya). 

f) Finalmente, para verificar la validez de la firma se 
comprueba la igualdad c = H3(k, m) devolviendo 
1 si la igualdad es válida y O en caso contrario. 


b) Ho(R, yg, (Y)",YA) y Cc 


c) 


d) 


b) 
c) 


d) 


(e, R, R, h, S1, 82), 


los dos primeros elementos (c, RR) son un código de auten- 
ticación del mensaje (MAC, en inglés) para el mensaje m, 
que puede ser verificado sólo si suficientes miembros de 
B cooperan. El resto de elementos (R,h, s1,s2) correspon- 
den a una prueba de conocimiento cero del logaritmo dis- 
creto de ya y de la igualdad entre los logaritmos discretos 
LogDisc, (RR) = DiscLog,(1). La verificación de dicha 
prueba de conocimiento se realiza en los pasos a) y b) del 
protocolo Ver_Dist. 


V. ANÁLISIS DE SEGURIDAD 


En este apartado demostramos que el esquema de firma con 
verificación distribuida propuesto en la sección anterior satis- 
face las propiedades definidas en la Sección II, alcanzando 
pues el máximo nivel de seguridad que se puede exigir a este 
tipo de firmas. 

La seguridad se considera en el modelo del oráculo aleatorio 
[1], donde el atacante puede hacer peticiones al oráculo que 
modela el comportamiento de ciertas funciones de hash. 

Basaremos la seguridad del esquema propuesto en los 
siguientes problemas computacionales. Dado un parámetro de 
seguridad A € N, un número primo q de A bits y un grupo 
cíclico G = (y) de orden primo q: 

+. El problema del Logaritmo Discreto (LD): para una 

entrada (G, y), tal que y € G, el objetivo del algoritmo 
ALP es encontrar un entero x € Z¿ tal que y = g”. Para 
un algoritmo en tiempo polinómico .44? que recibe la tu- 
pla (G, y), definimos Vent¿z»(A) como la probabilidad 
de que A encuentre ese valor x € Z¿ tal que y = y”. La 
hipótesis del Logaritmo Discreto asume que el problema 
LD es difícil de resolver, es decir que Ventyzp(A) es 
depreciable en A. 
+. El problema Computacional de Diffie-Hellman (CDH): 

para una entrada (G, g,g”, g?), tal que a,b € Z;, son 
valores aleatorios, el objetivo del algoritmo ACPH es 
calcular el valor de 9% € G. Definimos Ventcox(A) y 
la hipótesis Computacional de Diffie-Hellman de manera 
análoga al problema LD. 

La infalsificabilidad del nuevo esquema se basará en la difi- 

cultad de resolver el problema LD, mientras que la privacidad 

se basará en la dificultad de resolver el problema CDH. 


A. Infalsificabilidad 


Antes de proceder con la demostración de infalsificabilidad, 
recordamos una simplificación del Forking Lemma, intro- 
ducido por Pointcheval y Stern en [7]. 

Lema 1: [Forking Lemma modificado] Consideremos un 
esquema de firma digital genérico ? con parámetro de se- 
guridad A. Dado un algoritmo B que obtiene una firma 
válida (m, R, h, s) con probabilidad al menos e(A), existe otro 
algoritmo B' que utiliza B como subrutina y que produce 
con probabilidad e'(A) > O(e(A)?) dos firmas válidas 
(m, R,h,s) y (m,R!,h!,s”) tales que h HH. 

Las firmas genéricas tienen la forma (m, R,h,s), donde R es un valor 


aleatorio escogido dentro de un conjunto muy grande (de tamaño exponencial 
en el parámetro de seguridad), y h = H(m, R) para una función de hash H. 


A continuación demostramos por reducción que nuestro 
esquema de firma con verificación distribuida es infalsificable, 
en el modelo del oráculo aleatorio [1], basándonos en la 
suposición que el problema del logaritmo discreto es com- 
putacionalmente irresoluble en grupos de orden primo. 

Teorema 1: Sea A € N un parámetro de seguridad. Para 
cualquier atacante Fins contra la infalsificabilidad de nues- 
tro esquema de firma con verificación distribuida, existe un 
algoritmo AP para el problema del logaritmo discreto, 
esencialmente con el mismo tiempo de ejecución que NE, 
tal que 

Ventizo O) >0 (Vente (A)?) A 


Proof: Asumiendo que tenemos un atacante inF que 
tiene ventaja Ventz,¿(A) en romper la infalsificabilidad de 
nuestro esquema de firma, vamos a construir un algoritmo 
APR, que va a ir ejecutando a su vez el atacante Fine 
como subrutina, simulando su entorno y respondiendo a sus 
peticiones. Aplicando el Lema 1 al atacante Fine, el algoritmo 
ALP será capaz de resolver el problema del logaritmo discreto. 

ALP recibe como entrada un grupo cíclico G = (g) de 
orden primo q, junto con un valor y € G. El objetivo de 422 
es encontrar un entero x € Zy tal que y = 9”. 


INICIALIZACIÓN DE Finf. El protocolo X.Ini(14) es eje- 
cutado por ALP: éste da a Fins los valores params = 
(p, q,G, 9,2, Ho, H¡, Ha, H3). Aquí las funciones hash Ho : 
[0,1F* => (0,1%, H, : (0,1 > G y H3 : [0,1 > 
[0, 1)" son elegidas arbitrariamente por 44”. Sin embargo, 
H, es modelada como un oráculo aleatorio y por ello 44? 
mantendrá una tabla TAB que servirá para responder a las 
peticiones hash de Fin. 

Para simular la ejecución del protocolo 
.GC(params, A”, individual”), para el firmante A* 
escogido por Finf, el algoritmo 44” define la clave pública 
de A* como ya = y y se la envía a Finf. Nótese que la 
correspondiente clave secreta x 4», que es desconocida por 
ALP, es precisamente la solución buscada al problema del 
Logaritmo Discreto. 


GENERACIÓN DE NUEVAS CLAVES. El atacante Fins puede 
generar libremente nuevas claves públicas y secretas para otros 
firmantes A % A* y para colectivos (BB, T's) de verificadores 
de su elección. 


PETICIONES HASH. Como la prueba es en el modelo del 
oráculo aleatorio para la función hash Ha, FinfF puede hacer 
peticiones de esta función aleatoria. Para ello, 44? crea y 
mantiene una tabla TAB que responde de la siguiente manera 
a estas peticiones: la primera vez que se hace una petición, se 
escoge un valor aleatorio h € Z¿, se devuelve h a FinF, y se 
guardan los valores de la petición junto con el valor devuelto h 
en TAB. Si la misma petición se hace en el futuro, buscamos 
en la tabla y 44? responde con el mismo valor h que se 
encuentra en la salida existente. 


PETICIONES FIRMA. Cuando JFinF solicita firmas válidas 
para mensajes my y claves públicas yg, de su elección, donde 
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el firmante es A* y By es el colectivo de verificadores, ALP 
simula y devuelve firmas 0(m), de la siguiente manera: 

1) Elige un valor aleatorio r € Z¿ que le sirve para calcular 
R = g modp, k = Ho(R, Ye, (YB,)” Ya») ya= 
H3 (Le, ma). 

2) Elige valores aleatorios h,s1,s2 € Z¿ y calcula Y, = 
g%* - RP mod p, Ya = y” - (ya»)” mod p. 

3) Calcula g = Hi(c, R,Y¡, Y2,Ya*,YB,), y posterior- 
mente R = 3” mod p, Y, = 3% - R” mod p. 

4) Si la entrada (c, R, 3, R, Y, Ya, Yi, Yax, YB,) se encuen- 
tra en TAB (lo que ocurre con probabilidad desprecia- 
ble), se vuelve al paso 2. 

5) AL? “falsifica” el oráculo aleatorio para H3, imponiendo 
la relación h = Ha(c, R,g, R, Y,, Ya, Y, Ya», YB,) en 
TAB>. Más tarde, si Finf llamara al oráculo aleatorio 
con esa misma entrada, se le devolvería el valor h. 

6) Devuelve la firma 0(mp) = (c, R, R,h,s1,s2) a FinE. 

Es fácil comprobar que la firma devuelta es consistente, si no 
existen colisiones a la hora de “falsificar” el oráculo aleatorio. 


FALSIFICACIÓN. En algún momento inf produce con 
probabilidad Ventr,¿(A) una clave yg y una firma 
falsificada (m*,0*) para un conjunto de verificadores 
(B*,Tgstar), donde 0* = (c*,R*, R*,h*,st,s5) verifica 
las siguientes dos propiedades. Primero, la firma (m*,0*) 
debe ser diferente a las solicitadas anteriormente du- 
rante las peticiones de firma y segundo, se debe verificar 
Y Ver(params,m*,0*, ya», B,[sjtjeB) = 1, para algún 
subconjunto B € Ig». 

Puesto que la firma falsificada es válida, obtenemos que 
h = Ha(c*, R*,g*, Re, YI, YZ, Y f ya», yn»), donde Y = 
gi (ROO, Ya = 9 (ya), Ye = (gu. (Re)”. 

Además, puesto que esta falsificación es diferente de 
las firmas obtenidas durante las peticiones de firma, 
podemos estar seguros que la entrada petición  = 
(*,R*,9*, R* Y? YA, YY ya», ya») para Ha no ha sido 
*falsificada” y añadida a TAB, por 44”. 


REPLICANDO EL ATAQUE. Ahora podemos aplicar las 
técnicas de replicación del Forking Lemma modificado, des- 
crito en el enunciado del Lema 1. De manera informal, 
AR? repetirá la ejecución del adversario FinF, con la misma 
aleatoriedad pero cambiando los valores salida del oráculo 
aleatorio Ha para la entrada petición”. 

De esta manera, después que 44” ejecute dos ve- 
ces a Fins, obtendremos con probabilidad cuadrática en 
Ventra(A) (la probabilidad de obtener la primera firma 
falsificada) dos firmas válidas 0* = (c*, R*, R*,h*, st, s5) 
y 0% = (0%, RR, Msi, s'5) para los mismos valores 
(0, R* G*, Re, Y, YA, Y ya», ya») de Ha tales que h 4 
Pp. 

Puesto que las dos firmas son válidas, tenemos que 
9% - (ya) =Y3 =9%-(ya)”, 


lo cual implica que obtenemos la siguiente relación para el 
* Ik 1/(h *—h*) 
valor inicial y = Ya4+ = (9 ) : 


1 
sí—sy 


Por tanto, A4P devuelve el valor x = PF mod q y 
resuelve el problema del logaritmo discreto de y en base g, 
con probabilidad de éxito Ventyz»(A) > O (Venta, (A)?) . 

O 


B. Privacidad 


En el siguiente teorema demostraremos que nuestro es- 
quema de firma con verificación distribuida verifica la 
propiedad de privacidad definida en la Sección II, por re- 
ducción al problema computacional de Diffie-Hellman en 
grupos de orden primo. 

Teorema 2: Sea A € N un parámetro de seguridad. Para 
cualquier atacante Finp contra la privacidad de nuestro 
esquema de firma con verficación distribuida, existe un 
solucionador ACP del problema computacional de Diffie- 
Hellman, esencialmente con el mismo tiempo de ejecución que 
Finp, tal que 


Ventrcor(A) > Ventr lA) /2. 


Proof: Asumiendo que tenemos un atacante Finp que 
tiene ventaja Ventr,, (A) en romper la privacidad de nuestro 
esquema de firma, vamos a construir un algoritmo A4P% que 
irá usando a su vez a Finp como subrutina, para resolver el 
problema Computacional de Diffie-Hellman. 

El algoritmo 492% recibe como entrada un grupo cíclico 
G = (g) de orden primo q, junto con una tupla (g, g”, g?). El 
objetivo de ACPY es calcular g”. 


INICIALIZACIÓN DE Finp. El adverdario Finp escoge un 
conjunto de verificadores B* = (1,...,n), una estructura de 
acceso Pg+* E ga" y un subconjunto de participantes corruptos 
B¿Tp». 

ACDA simula una ejecución del protocolo Y.Ini(14): da a 
Fino los valores params = (p,q,G,9,l, Ho, Hi, Ha, H3), 
cuyas funciones hash Hoy, Hi y Ha2 las modelará como 
oráculos aleatorios, mientras que la función Hz : (0,1)* => 
10, 1)" la define explícitamente. Por tanto, AP4 mantendrá 
tres tablas TABy, TAB, y TAB que servirán para responder 
a las peticiones hash de Finp. 

La ejecución del protocolo 
.GC(params, B*,T'g», colectivo”) es simulada por 
ACPH de la siguiente manera: los fragmentos de los 
participantes corruptos, (s; ), eñ» Son elegidos aleatoria e 
independientemente en Z¿ y dados posteriormente a Finp. 
En este punto, 492% define la clave pública yg. = g” que 
también se envía a Finp. Remarcamos que esto significa que 
la clave secreta xpgx* asociada está definida implícitamente 
como b). 


GENERACIÓN DE NUEVAS CLAVES. El atacante Finp puede 
generar libremente nuevas claves públicas y secretas para 
firmantes A y para colectivos (B,T'g) 4 (B*,T'g+) de ve- 
rificadores de su elección. 


PETICIONES HASH. Como la prueba es en el modelo del 
oráculo aleatorio para las funcioness hash Ho, Hi y Ha, 
ACPH crea y mantiene tres tablas TAB¿, TAB, y TAB, que 
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simulan estas funciones hash. Para responder a las peticiones 
hash solicitadas por Finp, el atacante ACDH comprueba si ya 
existe una entrada en la correspondiente tabla para la entrada 
de esa petición. En ese caso, la salida existente es enviada a 
Finp. En caso contrario, una nueva salida es elegida aleato- 
riamente para ser enviada a Finp. Posteriormente, la relación 
entre la entrada y la salida es añadida a la correspondiente 
tabla. 

Para peticiones de Hy, A elige un valor aleatorio P € 
Z; y devuelve el valor y = (9”)P como nueva salida de H;. El 
valor 6 es guardado como valor adicional de la nueva entrada 
en la tabla TAB. 

En el caso que A“P* reciba peticiones de Hpy cuyos 
primeros valores sean g” y g?, el tercer elemento de la entrada 
será guardado en una tabla adicional TAB*. La tabla TAB* será 
la respuesta final de ACP% al problema CDH. 


CDH 


PETICIONES VERIFICACIÓN. Cuando JFinp solicita una 
petición de verificación (mo, 0, ya,) para firmantes Ap, con 
0 = (ce, Re, Re, ho, s10, 520), ACPH comprueba la validez 
de la prueba de conocimiento cero (Rp, hp, sip, $20). Para 
ello, obtiene mediante una petición hash el valor gy = 
Hi (cg, Re, go ] EP ga ? (Ya,)"*, Ya, YB») NN (go)? y 
verifica que se cumpla hy = Ha(cz, Re, Ge, Re, ga Ry ga. 
(ya 0,37 - Ri" ya, ym»). En el caso que no se cumpla, 
la respuesta de A“P% a la petición será 0. 

En caso contrario, A“PY debe calcular los valores 
(RF bhhies: y enviárselos a Finp. Para los participantes 
corruptos j € B, ACDH puede calcular estos valores 
fácilmente ya que conoce (s; e ¿- Además, como es válida 
la prueba de conocimiento de la igualdad de los logaritmos 
LogDisc, (RR+) = LogDisc,, (Re), siendo ge = g*P*, tenemos 


que EE * = Ry. Por tanto, ACPA puede calcular R7?* = 


di = AO Conociendo R7?*" y (R;? Jjez» el algoritmo 
ACPH puede usar en el exponente las relaciones lineales 
entre fragmentos y secretos, determinadas por el esquema para 
compartir secreto que realize I'g», y obtener el resto de valores 


Pibes 

Finalmente, A“PY ejecuta una petición hash 
Hol(Re,ye«, Ro? Ya.) = ke, actualizando la tabla 
TAB, en caso que esta petición sea nueva, y verifica si 
H3(k¿,mpe) = cy. Según el resultado de esa verificación, 


ACDH devuelve la salida 1 (firma válida) o O (firma no 
válida). 


DESAFÍO. En un momento dado, Finp escoge y publica dos 
mensajes mo, m1 de la misma longitud, junto con un firmante 
A* con valores (14=,Ya»). Ahora ACPA debe enviar una 
firma 0* a Finp, que obtiene de la siguiente manera: primero 
define R* = g” y elige valores aleatorios c* € (0,1, 
h*,si,s5 € Zg y P* € Z¿. Con estos valores APE define 
q =g8, Bt =(gU)8, Y =g 9 (REF, YS = 9% yan)” 
y Y 9 (Re). 

Si la entrada (c*, R*, Y, Y*,Yar,yB») ya existe en 
TAB;, o la entrada (0%, R* q, Re YA, YE YE ya, DÉ) ya 
existe en TAB, entonces 4P* elige nuevos valores aleato- 


rios c*,h*,si,sí y P*. Por último, las relaciones 7* = 
Hi(c*, R*,YF,YZ ya», ya») y h* = HA, REO RAE, 
YA, YY, Ya», YB») son añadidas a las tablas TAB, y TAB» 
respectivamente. 

La firma final 0* = 
atacante Finp. 


(c*, R*, R*,h*, sí, s3) es enviada al 


MÁS PETICIONES. El atacante Finp puede hacer más peti- 
ciones hash y de verificación, que son respondidas de igual 
manera a como ha sido descrito anteriormente. 

El único problema podría aparecer cuando JFinp pidiese 
una verificación de una firma válida (m,0,ya), con O = 
(c, R,R, h, s,, 52) tal que el valor g = H,(c, R, g% - R?, gs2. 
(ya)”,ya, yn») coincidiese con el valor g* = gf%”, ya que 
este último valor no tiene por qué ser de la forma (99). 
Sin embargo, esto ocurriría únicamente cuando los valores 
de entrada de A; tanto para esta firma como para la firma 
del desafío fuesen los mismos. Puesto que las pruebas de 
conocimiento cero son válidas, obtendríamos que los valores 
R son iguales en ambos casos y, por tanto, que los valores 
h,s1,52, YA también deberían ser iguales. La conclusión es 
que la firma solicitada O sería la misma que la firma 0* del 
desafío. Como esto está prohibido por definición, nunca nos 
encontraremos con este caso. 


ANÁLISIS FINAL. Finp devuelve un bit b' con el que gana 
el juego con una probabilidad significativamente mayor que 
1/2. Puesto que Hy se comporta como una función aleatoria, 
Finp puede ganar sólo si Finp ha preguntado anteriormente al 
oráculo aleatorio el valor Hy(g”, g?,g“, y 4.) correspondiente 
al desafío 9*. Por tanto, con una probabilidad no despreciable 


por 
blema CDH. Tal y como indican los autores de [9], podríamos 
usar el auto-corrector Diffie-Hellman descrito en [8] para 
transformar al atacante A9P% en otro que en vez de devolver 
toda una lista de candidatos TAB*, devuelve únicamente la 
solución correcta del problema CDH. m 


Cabe remarcar que en contraposición al esquema propuesto 
en [6], que sólo asolía la privacidad débil, el esquema pro- 
puesto aquí es seguro incluso frente a adversarios que pueden 
hacer peticiones a un oráculo de verificación. 
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Resumen—El auge del comercio electrónico esta impulsando 
la migración de procesos y aplicaciones tradicionales (en papel) 
al modelo electrónico, pese a que algunos aspectos relaciona- 
dos con el comercio electrónico no estén bien solucionados, 
como por ejemplo, el Intercambio Equitativo de Valores en la 
Firma Electrónica de Contratos. Por otra parte, los Servicios 
Web (Web Services) se están convirtiendo en el standard para 
la interconexión de aplicaciones y procesos en entornos B2B 
(Business to Business). Pero no existen propuestas basadas en 
Servicios Web para solucionar el Intercambio Equitativo de 
Valores en la Firma Electrónica de Contratos. Además, las 
soluciones suelen presentarse desde un punto de vista técnico, 
olvidando los aspectos legales. 

En este artículo, presentamos una propuesta para la imple- 
mentación de un servicio de contratación electrónica basado en 
la tecnología de Servicios Web, que cumple con los requisitos 
legales y técnicos necesarios; también analizamos la adecuación 
de ésta a un entorno de aplicación real. La propuesta demuestra 
que es posible diseñar soluciones para la firma electrónica de 
contratos, con tecnología de Servicios Web, que cumplan los 
requisitos legales y técnicos. Finalmente, se pone de manifiesto la 
utilidad de estos servicios en aplicaciones de comercio electrónico, 
y las complicaciones que surgen a la hora de trasladar un 
diseño teórico (el desarrollo de un protocolo), a un entorno real 
(aplicaciones existentes). 


I. INTRODUCCIÓN 


La utilización de Internet como canal de ventas ofrece 
grandes ventajas a clientes y consumidores. El constante 
crecimiento del uso de Internet en el ámbito del comercio 
electrónico lo atestigua. Pero la seguridad de las transacciones 
electrónicas sigue suponiendo un obstáculo a su expansión. 
Aún así, debemos reconocer que se han realizado grandes 
esfuerzos para crear un marco jurídico adecuado y obtener 
soluciones desde el punto de vista técnico. Centrándonos 
en la contratación electrónica, encontramos múltiples con- 
tribuciones en la literatura científica, pero ninguna de ellas 
ha sido capaz de evolucionar hasta conseguir un nivel de 
estandarización O adquirir un puesto relevante dentro de las 
soluciones comerciales, por lo que carecemos de estándares y 
estándares de facto. 

Además, empresas e instituciones encuentran dificultades 
a la hora de interoperar con segundas o terceras partes. 
Históricamente, han existido soluciones que han intentado 
superar este obstáculo y facilitar la interoperabilidad entre 
aplicaciones y procesos, por ejemplo EDI (Electronic Data 
Interchange), pero nunca lograron un éxito generalizado. En 
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este ámbito, los Servicios Web se postulan como la tecnología 
que finalmente será capaz de conseguirlo. De ahí el interés de 
combinar una fase esencial del comercio electrónico, la fase 
de contratación, con la tecnología de los Servicios Web. 

Desde un punto de vista de seguridad, la firma digital de 
contratos es un problema de Intercambio Equitativo. Cada 
parte involucrada en la transacción tiene un elemento que 
quiere entregar a cambio de otro elemento, pero nadie quiere 
dar su parte a no ser que obtenga el elemento intercambiado 
por la otra parte. Como ejemplo, podemos pensar en comprar 
a través de Internet, donde intercambiamos productos o ser- 
vicios por un pago. Otra aplicación típica, sería el traslado 
de contratos basados en papel a contratos digitales, y sus 
implicaciones: negociación, generación de documentos, etc. 

El objetivo de nuestra investigación es proponer soluciones 
para desarrollar servicios de firma electrónica de contratos 
basados en tecnología de Servicios Web y protocolos optimis- 
tas, que no requieren intervención directa de la TTP (Trusted 
Third Party). En este artículo presentamos una solución que 
demuestra que es posible diseñar servicios de firma electrónica 
que cumplan los requisitos técnicos y legales necesarios, y 
analizamos las implicaciones y requerimientos derivados del 
desarrollo de aplicaciones de este tipo. 


II. EJEMPLO DE APLICACIÓN: AGENCIAS DE VIAJES 


En la figura 1 tenemos un ejemplo de aplicación de Ser- 
vicios Web: Integración de aplicaciones B2B en entornos de 
servicios turísticos. Típicamente, las agencias de viajes cuen- 
tan con aplicaciones internas hechas a medida para gestionar 
sus reservas, peticiones, inventarios, etc. Al permitir que a 
través de Servicios Web entidades externas puedan acceder 
a sus procesos internos, como proveedor, les permite ofrecer 
servicios en tiempo real, incrementa su eficiencia y aumenta 
sus posibilidades de negocio. Además, como consumidores 
de servicios ofrecidos por mayoristas, les permite acceder a 
múltiples proveedores externos incrementando su oferta de 
servicios y mejorando su competitividad. En un escenario 
como éste, se podría utilizar un servicio de contratación 
electrónica para mantener un registro de transacciones, con 
validez legal, y para conseguir acceso a nuevos proveedores 
mediante la firma electrónica de contratos. 


Web Service 
Provider B 


Web Service 
Provider A 


Web Client 
(end user) 


Figura 1. Ejemplo de aplicación 


IFA. Business 2 Business, B2B 


Las agencias de viajes suelen ofrecer servicios de trans- 
porte, alojamiento, etc. Para poder adquirir un servicio, el 
cliente/consumidor tiene que ejecutar una petición de cierre 
de reserva (bookingClose), que típicamente sigue un esque- 
ma petición-respuesta. La información incluida en ambos 
mensajes dependerá de cada tipo de servicio, y de cómo 
esté implementado. Pero ambos tienen en común el hecho de 
que la operación de cierre de reserva implica un intercambio 
equitativo: un usuario intercambia un servicio por un pago. La 
respuesta del cierre de reserva es el recibo de la transacción, 
donde el proveedor envía al cliente toda la información sobre 
el servicio, incluyendo la referencia (localizador) y algunas 
veces un Bono que se le reclamará al cliente al llegar a destino. 
En este caso, se podría utilizar el servicio de contratación para 
mantener un registro de transacciones. 


Las agencias suelen ofrecer servicios internos y externos, a 
través de terceros. Utilizando Servicios Web, una agencia de 
viajes puede acceder a proveedores externos para mejorar su 
competitividad y oferta de servicios. Teóricamente, utilizando 
Servicios Web, una agencia de viajes debería ser capaz de 
encontrar proveedores de manera automática, dependiendo 
de la petición. Este descubrimiento y ejecución en tiempo 
real puede conseguirse si limitamos su aplicación. En lugar 
de buscar cualquier tipo de proveedor, podemos acotar la 
búsqueda a proveedores que utilicen un tipo de datos específi- 
co, como el que ofrece la OTA (Open Travel Alliance). La 
negociación del contrato puede simplificarse, aceptando un 
modelo de contrato de antemano. Los problemas de confianza 
entre usuarios y proveedores puede solventarse con la creación 
de registros seguros y privados de servicios UDDI (Universal 
Description Discovery and Integration), donde sólo usuarios y 
proveedores de confianza tengan acceso. Finalmente, podemos 
utilizar el servicio de contratación electrónica para firmar un 
contrato/acuerdo con el proveedor y conseguir acceso a sus 
servicios. 
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TT. 


Podemos distinguir dos tipos de líneas dentro de la literatura 
de trabajos previos relacionados con este artículo: los enfoca- 
dos a proponer soluciones de firma electrónica en entornos de 
Servicios Web, y los enfocados a la propuesta de soluciones 
para la contratación electrónica. 


TRABAJO PREVIO 


HILA. Firma electrónica en entornos de Servicios Web 


Pese a que existen un gran número de propuestas de 
protocolo para la firma electrónica de contratos, en lo que se 
refiere a propuestas de implementación basadas en Servicios 
Web, el número de publicaciones es sorprendentemente muy 
bajo. Maruyama et al. [1], propone un servicio basado en el 
protocolo presentado por Asokan et al. [2], donde presenta 
una breve descripción de la implementación del servicio de 
firma electrónica. Se definen dos estructuras XML (eXtensible 
Markup Language) diferentes para contratos válidos y las 
estructuras para cada transacción. Los contratos se representan 
como conjuntos de aserciones en formato SAML (Security 
Assertion Markup Language) y las firmas digitales como 
estándares XML dsig (XML Signature Syntax and Processing). 
Aunque la implementación es válida, creemos que al pre- 
definir la estructura de los contratos, limita su posibilidad de 
aplicación en entornos reales. Robinson et al. [3] proponen 
un servicio de firma electrónica de contratos basado en el 
protocolo de Zhou y Goldman [4], y Garbinato y Rickebush 
[6] presentan un protocolo para el intercambio equitativo en 
entornos de Servicios Web, basada en el uso de módulos 
hardware a prueba de manipulaciones y enfocada a solucionar 
el problema de los Generales Bizantinos. Ambas propuestas 
incluyen la utilización de una tercera parte de manera activa 
(un agente externo y módulos hardware), mientras que la 
nuestra pretende evitar el uso de terceras partes utilizando 
protocolos optimistas. 


HIF-B. Contratación Electrónica 


En el campo de la contratación electrónica, la mayoría de 
los esfuerzos de investigación están enfocados a resolver el 
problema desde el punto de vista de procesos de negocio, 
ignorando o dejando de lado los problemas de seguridad: 
se intenta automatizar el hecho que una relación contractual 
entre entidades debe cumplir con una serie de derechos y 
obligaciones definidos en un contrato, y detectar posibles 
desviaciones o incumplimientos de éstas. Tienen como obje- 
tivo la descripción del conjunto de funcionalidades necesarias 
para ejecutar el proceso entero, desde la definición/negociación 
del contrato hasta su ejecución, controlando que no haya 
desvíos ni incumplimientos. Un buen ejemplo en este campo 
de investigación, es el artículo de Karlapalem y Krishna [7], 
donde nos presentan una revisión del trabajo realizado en este 
ámbito, y proponen una solución para la ejecución del contrato 
electrónico, sin que los autores hagan referencias específicas a 
la firma de contratos. En un artículo más reciente, Angelov y 
Grefen [8] presentan un diseño completo de una arquitectura 
que cubre el proceso completo de contratación electrónica. 
Al contrario que en el artículo de Karlapalem y Krishna [7], 


en éste sí que encontramos referencias explícitas a la firma 
electrónica de contratos como parte importante de la fase de 
Contratación. Define los requisitos de seguridad que el sistema 
debe cumplir y sus módulos de seguridad. Pero de nuevo falla 
a la hora de describir cómo se lleva a cabo ese proceso de 
firma de contratos. 


IV. REQUISITOS 


Las bases de nuestra investigación son el marco legal de la 
firma electrónica, los Servicios Web y los protocolos de firma 
electrónica de contratos. Cada uno de estos ámbitos tiene sus 
propios requisitos, por lo que deberemos cumplir con todos 
ellos. 

La firma electrónica de contratos es un caso particular de 
Intercambio Equitativo, cuyos requerimientos fueron formu- 
lados por Asokan et al. [2] y más tarde reformulados por 
Zhou et al. [9]: efectividad, equidad, timeliness, no-repudio 
y verificabilidad. Para asegurar el cumplimiento de éstos, uti- 
lizaremos la versión simplificada de 2 partes, del protocolo de 
firma electrónica de contratos presentado por Ferrer-Gomila ef 
al. [5]. Se trata de un protocolo optimista en el que se definen 
3 sub-protocolos: intercambio, cancelación y finalización. Si 
las 2 partes implicadas se comportan honestamente, se ejecuta 
el sub-protocolo de intercambio y no es necesaria la interven- 
ción de la TTP; los protocolos de cancelación y finalización 
se utilizan para resolver posibles conflictos. En la tabla 1 
podemos ver la nomenclatura y elementos que intervienen 
en el protocolo y en las tablas 1, III y IV, la descripción 
de los 3 sub-protocolos. En el artículo donde se presenta el 
protocolo (Ferrer-Gomila ef al. [5]) se puede encontrar un 
análisis completo sobre la seguridad del protocolo. 

Algunas de las razones del éxito de los Servicios Web 
son, entre otras, su independencia de plataforma y lenguaje 
de programación, y el hecho de que los Servicios Web se 
basan en tecnologías de estándares abiertos. Por ello nuestra 
propuesta también deberá estar basada en estándares abier- 
tos y ser independiente de plataforma y lenguaje. También 
debemos asegurar que los beneficios derivados del uso de esta 
tecnología son mayores que los costes, pues de los contrario 
carecerá de utilidad. 

En el artículo de Ferrer-Gomila et al. [11] se puede encon- 
trar una discusión sobre los aspectos legales del protocolo de 
firma electrónica utilizado en la propuesta presentada en este 
artículo. A destacar, decir que la Directiva de la Union Europea 
2000/31/EC [10], con fecha 8 de Junio del 2000 apunta a un 
sistema de firma electrónica de 3 fases: 


1. Una compañía envía una oferta utilizando medios elec- 
trónicos (un producto o servicio puesto a la venta). 

2. Un consumidor (u otra compañía) envía una or- 
den/petición (en relación a la oferta anterior), utilizando 
medios electrónicos (en términos jurídicos se puede 
denominar Aceptación). 

3. La primera compañía debe enviarle al cliente (o segunda 
compañía) el acuse de recibo de la Aceptación que el 
consumidor le envío. 
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V. PROPUESTA DE IMPLEMENTACIÓN 
V-A. Mensajes y Evidencias 


Antes de empezar el diseño de la aplicación, debemos 
decidir a qué llamamos Mensaje y a qué llamamos Evidencia. 
Las evidencias son las pruebas que se generan durante la 
ejecución del protocolo y que permiten a A o B demostrar, en 
caso necesario, que el contrato ha sido firmado o cancelado. 
Desde el punto de vista del protocolo es muy sencillo, en las 
tablas II a IV tenemos definidos para cada paso, el mensaje 
a enviar. Por ejemplo, en el primer paso del sub-protocolo 
de intercambio, el mensaje es: M,ha, y se envía de A a B. 
Este mensaje incluye una evidencia, ha, la firma digital de A 
sobre el contrato M. Pero al intentar trasladar el protocolo a 
una aplicación real, y en particular a una aplicación basada 
en Servicios Web, la definición de mensaje y evidencia no 
es tan sencilla. Los Servicios Web intercambian información 
en forma de mensajes XML encapsulados en SOAP (Simple 
Object Access Protocol), mientras que las aplicaciones que ha- 
cen uso de esos Servicios Web para comunicarse, intercambian 
mensajes XML. Por ello debemos decidir a qué nivel queremos 
implementar el protocolo: identificar los mensajes definidos 
en el protocolo como los mensajes XML intercambiados 
entre aplicaciones o los mensajes SOAP intercambiados por 
los Servicios Web. Aunque pueda parecer irrelevante, esta 
decisión conlleva consecuencias: 


= Determinará lo que serán las evidencias y la definición 
de los tipos XML. 

= Afectará al número de estándares, herramientas y tec- 
nologías disponibles para implementar el servicio, como 
el estándar WSS (Web Services Security), que define 
cómo enviar XML firmados y/o cifrados mediante SOAP. 

= Para facilitar la implementación de aplicaciones con 
Servicios Web, existen varias herramientas que pueden 
construir Servicios Web de manera automática (Java 
Axis2, .NET.,...), a partir de su descripción en WSDL 
(Web Services Description Language). Si escogemos 
definir los mensajes como mensajes de aplicación XML, 
obtendremos una solución a medida, particular para esa 
aplicación, mientras que si utilizamos los mensajes SOAP 
como mensajes del protocolo, obtendremos una solución 
más homogénea. Incluso podemos llegar a encontrar una 
solución que nos permita describir el servicio de manera 
estándar y generarlo automáticamente utilizando alguna 
herramienta. 


Para la solución presentada en este artículo, hemos escogido 
definir los mensajes como los tipos de datos XML intercambi- 
ados entre las aplicaciones, para enfocar nuestros esfuerzos en 
la comprensión de las implicaciones de transformar la teoría 
(descripción de un protocolo) en práctica (aplicaciones reales), 
y su viabilidad. 


V-B. Diseño del WSDL 


El objetivo final es definir en formato WSDL el servicio de 
firma digital de contratos. Para ello, lo primero que debemos 
hacer es definir los tipos de datos, transformar los elementos 


M 
ha =PRaA[H(M) 


har = PReiH(H(M 
hg = PRr[A(hg)] 

Ca = PRr[H (cancelled, ha)] 
CB = PRrp[H (cancelled, hg)] 


El contrato a firmar 

firma digital de A sobre el contrato M 

firma digital de B sobre el contrato M 

firma digital de A sobre hp. Evidencia de la firma de A. 

firma digital de la TTP sobre hp. Evidencia equivalente a ACKa 
Evidencia que A ha pedido la intervención de la TTP 

Evidencia que B ha pedido la intervención de la TTP 


firma digital de la TTP sobre hg como prueba de su intervención 


Evidencia de A, como prueba que la firma ha sido cancelada 
Evidencia de B, como prueba que la firma ha sido cancelada 


Tabla I 


NOTACIÓN Y ELEMENTOS UTILIZADOS EN EL PROTOCOLO 


del protocolo M, ha halo; etc. en estructuras de datos 
XML. Como podemos apreciar en la tabla I, lo que tenemos 
son un contrato M y firmas digitales. No entraremos en el 
problema de cómo definir un contrato, puesto que es muy 
complejo, y entendemos que el contrato debe amoldarse a cada 
aplicación en particular. Nosotros hemos definido una sencilla 
estructura con nombre, contenido, fechas, lista de precios, etc. 
Para las firmas digitales, utilizaremos el estándar XMLdsig, 
junto con XAdES, una extensión que cumple con la Directiva 
1999/93/EC del Parlamento Europeo y el Consejo del 13 de 
Diciembre de 1999, que establece un marco Europeo para la 
firma digital. En particular, utilizaremos el formato de firma 
XML Detached, siguiendo las recomendaciones del WS-I 
(Web Services Interoperability Organization) en su documento 
Basic Security Profile 1.0. 

Una vez definidos los tipos de datos, debemos definir los 
mensajes. En la sección IV hemos visto como la normativa 
Europea apunta a la firma electrónica en 3 pasos, los mismos 
que tiene el sub-protocolo de intercambio elegido. Así pues, 
cada paso del sub-protocolo de intercambio será un mensaje 
distinto. Para los protocolos de Cancelación y Finalización, 
definiremos un mensaje de petición y uno de respuesta que 
incluya las 2 posibles respuestas. 

Para definir las operaciones debemos analizar el tipo de 
transacciones ejecutadas en cada sub-protocolo y encontrar su 
equivalente, si existe, en WSDL. La versión 1.1 de WSDL 
define 4 tipos posibles (llamados transaction primitives): 


= One-way: El servidor recibe un mensaje. 

= Request-Response: El servidor recibe una petición y 
envía su correspondiente respuesta. 

= Solicit-Response: El servidor envía una petición al 
cliente, y éste le envía una respuesta. 

= Notification: El servidor envía un mensaje al cliente. 


El sub-protocolo de intercambio se ejecuta en 3 pasos, que no 
coincide con ninguna de las posibles transacciones definidas 
para WSDL 1.1, por lo que deberemos describir el sub- 
protocolo en 2 operaciones distintas. Para que la imple- 
mentación cumpla con los requerimientos legales vistos en la 
sección IV, la oferta, primer mensaje, debe enviarlo la com- 
pañía o proveedor. Por lo tanto el primer mensaje deberá ser 
de tipo Notification O Solicit-Response. Para nuestro diseño, 
hemos escogido que el paso 1 (oferta) sea una operación 
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Exchange Sub-Protocol 


Tabla II 
SUB-PROTOCOLO DE INTERCAMBIO 


de tipo Notification, y los pasos 2 (Aceptación) y 3 (Acuse 
de recibo de aceptación) sean de tipo Request/Response. En 
el caso de los sub-protocolos de cancelación y finalización, 
deberemos definir una operación de tipo Request/Response 
para cada caso. 


Hasta este punto hemos realizado una definición abstracta de 
los servicios, sin especificar dónde se ejecutarán, qué protocolo 
de transporte se utilizará o cómo se formatearán los mensajes. 
Para ello, debemos agrupar las operaciones en PortTypes, 
conjuntos de operaciones ejecutados en el mismo punto final 
(servidor) y especificar, para cada uno de ellos, el protocolo de 
transporte y formato de mensajes, Binding. Al especificar las 
agrupaciones de operaciones, debemos tener en cuenta que nos 
interesa mantener separadas las operaciones de cancelación y 
finalización, de manera que más adelante podamos definir un 
servicio independiente para cada una de ellas. Aunque las dos 
operaciones son ejecutadas en el mismo punto final, la TTP, 
es la entidad A quien ejecutará la operación de cancelación, y 
la entidad B quien ejecutará la de finalización, tal y como se 
indica en el protocolo. Por lo tanto, vamos a definir un punto 
de acceso distinto para cada una de ellas. 


Así pues, definiremos 3 agrupaciones de operaciones dis- 
tintas (PortTypes), una para cada servicio: intercambio, can- 
celación y finalización. Para cada agrupación, especificaremos 
como protocolo de transporte HTTP y para el formato de 
mensajes SOAP. 


El último paso es definir cada servicio, asignándole un punto 
de ejecución y agrupaciones de operaciones. Definiremos 3 
servicios: intercambio (ejecutado en la entidad A, proveedor), 
cancelación y finalización (ambos ejecutados en la T'TP, pero 
con distinta URL). El resultado final está disponible en: 
“http://secom.uib.es/gerard/wsdl.zip”. 


Cancel Sub-Protocol 


A => TTP H(M),ha har 
Tf finished = true 

TIP retrieves hg 
TIPA hgshy 


Else cancel signature 
TIP>A Ca 
02 stores cancelled = true 


Tabla HI 
SUB-PROTOCOLO DE CANCELACIÓN 


Finish Sub-Protoco! 


If cancelled = true 
TIP>B CB 


Else finish signature 
TIP>A  ACKrT— 


TUP stores finished = true 


Tabla IV 
SUB-PROTOCOLO DE FINALIZACIÓN 


vi. 
VI-A. Requisitos Técnicos 


CUMPLIMIENTO DE LOS REQUISITOS 


Los requisitos técnicos que debe cumplir la propuesta de 
diseño son los enunciados en la sección IV: efectividad, 
equidad, timeliness, no-repudio y verificabilidad. 

Hemos diseñado nuestros servicios para que, por cada 
elemento de información definido en el protocolo (ver tabla 
ID), tenemos un equivalente definido como XML. Es más, 
si pensamos en cada transacción definida en el protocolo 
como una operación, podemos comprobar como en el diseño 
realizado tenemos definidas las mismas operaciones en el 
mismo orden. Además, las evidencias, firmas digitales en 
la definición del protocolo, han sido trasladadas a firmas 
digitales (XMLdsig) en el diseño de la implementación. Es 
más, hemos decidido utilizar la extensión XAdES de XMLdsigz, 
para cumplir con la Directiva 1999/93/EC del Parlamento 
Europeo y el Consejo del 13 de Diciembre del 1999, que 
define un marco común para la firma electrónica. Puesto que 
el protocolo escogido demuestra cumplir todos los requisitos 
técnicos (ver Ferrer-Gomila et al. [5]), y que la aplicación 
ha sido diseñada para tener el mismo flujo de ejecución, 
intercambiar la misma información en el mismo orden, y 
generar las mismas evidencias, podemos afirmar que nuestra 
propuesta cumple con las propiedades de efectividad, equidad, 
timeliness, no-repudio y verificabilidad. 


VI-B. Requisitos Legales 


Al utilizar XAdES como formato de firma electrónica, 
cumplimos con el marco legal de la Union Europea para la 
firma digital (Directiva 1999/93/EC del Parlamento Europeo 
y el Consejo del 13 de Diciembre de 1999). Además, la 
propuesta presentada sigue el flujo de ejecución: Oferta- 
Aceptación-Acuse de recibo, al que apunta la Directiva de 
la Union Europea 2000/31/EC, con fecha 8 de Junio del 2000 
[10], que establece el marco legal de la Unión Europea para 
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la contratación electrónica. Por tanto podemos afirmar que la 
aplicación cumple con los requisitos legales existentes en la 
actualidad. 


VII. ADECUACIÓN A LAS APLICACIONES 


Partiendo de un protocolo optimista (Ferrer-Gomila et al. 
[5]) válido, que ha demostrado cumplir con las características 
técnicas y requisitos legales (Ferrer-Gomila et al. [11]), hemos 
diseñado una aplicación basada en la tecnología de Servicios 
Web cumpliendo esos mismos requisitos. En la sección Il, 
hemos presentado un ejemplo de entorno real en el que se 
aplica la tecnología de los Servicios Web, y se han planteado 
dos posibles aplicaciones del protocolo para este entorno: un 
registro de transacciones y una aplicación de firma electrónica 
de contratos. Ahora nos queda comprobar si la aplicación 
presentada es apta para utilizarse en la creación de un registro 
de transacciones y firma electrónica en el entorno propuesto. 


VIFA. Registro de transacciones 


Como registro de transacciones afectaría a la operación de 
cierre de reserva BookingClose. Se trata de una operación de 
tipo petición/respuesta, en la que el cliente envía una petición 
para reservar uno o más servicios. Cuando el proveedor recibe 
la petición (BookingCloseRequest) y confirma su validez, 
cierra la reserva (la venta se ejecuta) y genera el localizador 
de reserva o el bono que el consumidor necesitará para poder 
utilizar el servicio. Esta información se envía al consumidor 
en la respuesta de cierre de reserva (BookingCloseResponse). 


= Primero, siguiendo los requisitos legales, el flujo de 
ejecución del registro de transacciones debe ser: A —> B, 
A <= B, A > B, siendo A el proveedor y B el 
consumidor. Esto implica que la operación de cierre de 
reserva pasará de tener 2 pasos a tener 4 (el primer 
mensaje, sera la respuesta del cierre, de A —> B). 
Duplicar el número de transacciones significa aumentar 
la probabilidad de que se produzcan errores, disminuir la 
eficiencia del sistema y aumentar el tiempo de respuesta. 

= Segundo, al mapear la respuesta del cierre de reserva con 
el inicio del registro de transacciones, podemos perder 
la equidad, y dejar al proveedor en desventaja. Esto es 
así debido al funcionamiento interno de este tipo de 
aplicaciones: el proveedor recibe una petición de reserva; 
si la petición es correcta, procede a cerrar la reserva, bien 
en su sistema interno (aplicación propia) o bien enviando 
una petición a su proveedor externo. En cualquiera de los 
casos, cuando el proveedor responde al cliente, él ya ha 
ejecutado el cierre de la reserva, lo que quiere decir que 
si el cliente decidiese echarse atrás, el proveedor debería 
correr con los gastos de cancelación, en el caso de que 
los hubiera. 

= Tercero, podríamos argumentar que el flujo de ejecución 
necesario para cumplir los requisitos legales es: A —> B, 
A <= B,A > B, siendo A el consumidor y B el provee- 
dor, disminuyendo así el número de pasos a ejecutar, 
de 4 a 3. Pero volveríamos a perder equidad, en este 
caso, sería el consumidor el que la perdiese. Si revisamos 


el sub-protocolo de intercambio (ver tabla II), vemos 
que el mensaje que se firma, del que hay evidencias, 
es M, enviado desde el consumidor al proveedor en el 
primer paso (asumiendo A = consumidor). El problema 
viene dado por el hecho de que en la realidad no es 
así. En la respuesta del cierre de reserva se le envía al 
cliente el localizador y/o el bono de la reserva, necesarios 
para poder ejecutarla. Si no conseguimos evidencias que 
relacionen la transacción con esta información adicional, 
el proceso es inútil. 

Por lo tanto, podemos decir que pese a haber diseñado una 
aplicación cumpliendo todos los requisitos teóricos y legales 
necesarios, a la hora de utilizar esta aplicación en un entorno 
real, que teóricamente encaja en el problema, los resultados 
no son satisfactorios. Debemos seguir trabajando para acercar 
las soluciones teóricas, en este caso un protocolo, a las 
aplicaciones reales y conseguir así las mejoras y beneficios 
perseguidos con el diseño de esas soluciones. 


VIF-B. Firma digital de contratos 


En el caso de la aplicación de firma digital de contratos 
propuesta en la sección II, la firma de un contrato implica 
la ejecución del sub-protocolo de intercambio. Si pensamos 
en el mundo no electrónico, la identificación de la entidad A 
como proveedor y la entidad B como consumidor, además de 
cumplir los requisitos legales, es la lógica. Es el proveedor 
quien nos propone un contrato ofreciendo sus servicios. Otra 
posible utilidad de la aplicación presentada en este artículo 
es la ejecución de la firma digital en un entorno como el 
presentado en el artículo de Angelov y Grefen [8], donde se 
define la arquitectura de un sistema de contratación electrónica 
definiendo un componente específico encargado de la ejecu- 
ción de la firma. 

El único obstáculo que nos podría presentar la aplicación 
propuesta es el hecho de que el primer paso en la ejecución 
del sub-protocolo de intercambio está definido como una 
operación de tipo Notification, un mensaje enviado desde el 
proveedor al consumidor. En la práctica, esto implica que 
el consumidor debe tener en marcha un servicio para poder 
atender el mensaje de propuesta de contrato enviado por el 
proveedor. 


VIII. 


En este artículo hemos presentado una propuesta para la 
implementación de un servicio de Firma Electrónica de Con- 
tratos que cumple con los requisitos técnicos y legales que 
hemos formulado en la sección IV. Aunque no se trate de una 
solución estándar, demuestra que es posible diseñar servicios 
que cumplan ambos requisitos, y nos ayuda a comprender 
los problemas que surgen al intentar implementar soluciones 
reales (Firma de Contratos y Registro de Transacciones). 

Hemos visto que una aplicación de firma electrónica se 
puede utilizar para varios propósitos, como registro de transac- 
ciones o para ejecutar firmas digitales, como función principal 
en un proceso de firma electrónica de contratos. Cada usuario 
tiene diferentes necesidades: como registro de transacciones 
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normalmente requerirá soluciones síncronas, mientras que un 
servicio de firma digital de contratos puede requerir soluciones 
asíncronas, debido a la necesidad de intervención humana o 
de ejecución de procesos que consuman mucho tiempo. El 
diseño de un servicio basado en mensajes de aplicación XML 
nos llevará a soluciones hechas a medida para cada usuario, 
asegurándonos satisfacer todas sus necesidades, pero con un 
alto grado de incompatibilidad entre aplicaciones de distintos 
distribuidores. Por otra lado, las implementaciones basadas en 
mensajes SOAP nos permiten aprovechar estándares existentes 
como WSS, consiguiendo soluciones más homogéneas. 

El siguiente paso en nuestra investigación será la exten- 
sión del trabajo a propuestas de protocolos de N-partes y 
la adecuación de los diseños a las propuestas de aplicación 
presentadas. 


AGRADECIMIENTOS 


Este trabajo ha sido financiado por una beca FPI ligada 
al proyecto de investigación TSI2007-62986 del Ministerio 
de Ciencia e Innovación (MICINN) de España, cofinanciada 
por el Fondo Social Europeo y el proyecto de investigación 
Consolider, con referencia CSD2007-00004, del MICINN. 


REFERENCIAS 


[1] H. Maruyama, T. Nakamura, T. Hsieh, Optimistic fair contract signing 
for web services, in: XMLSEC 03: Proceedings of the 2003 ACM 
workshop on XML security, ACM, New York, NY, USA, 2003, pp. 
79-85. doi:http://doi.acm.org/10.1145/968559.968572. 


[2] N. Asokan, V. Shoup, M. Waidner, Asynchronous  protocols 
for optimistic fair exchange, in: Security and Privacy, 1998. 
Proceedings. 1998 IEEE Symposium on, 1998, pp. 86-99. 


doi:10.1109/SECPRI.1998.674826. 

P. Robinson, N. Cook, S. Shrivastava, Implementing fair non-repudiable 

interactions with web services, in: EDOC ”05: Proceedings of the 

Ninth IEEE International EDOC Enterprise Computing Conference, 

IEEE Computer Society, Washington, DC, USA, 2005, pp. 195-206. 

doi:http://dx.doi.org/10.1109/EDOC.2005.16. 

[4] J.. Zhou, D.  Gollmamm, Evidence 

J.  Netw.  Comput.  Appl. 20 

doi:http://dx.doi.org/10.1006/jnca.1997.0056. 

J. L. Ferrer-Gomila, M. Payeras-Capelláa, L. H. i. Rotger, Efficient 

optimistic n-party contract signing protocol, in: ISC ”01: Proceedings 

of the 4th International Conference on Information Security, Springer- 

Verlag, 2001, pp. 394-407. 

B. Garbinato, I. Rickebusch, Orchestrating fair exchanges between 

mutually distrustful web services, in: SWS ”06: Proceedings of the 3rd 

ACM workshop on Secure web services, ACM, New York, NY, USA, 

2006, pp. 33-42. doi:http://doi.acm.org/10.1145/1180367.1180375. 

[1 E. R. Krishna, K. Karlapalem, Electronic contracts, 
TEEE Internet Computing 12 (4) (2008) 60-68. 
doi:http://doi.ieeecomputersociety.org/10.1109/MIC.2008.77. 

[8] S. Angelov, P.  Grefen, An  e-contracting reference  ar- 

chitecture,  J.  Syst.  Softw. 81 (11) (2008) 1816-1844. 

doi:http://dx .doi.org/10.1016/;.jss.2008.02.023. 

J. Zhou, R. H. Deng, F. Bao, Some remarks on a fair exchange protocol, 

in: PKC ”00: Proceedings of the Third International Workshop on 

Practice and Theory in Public Key Cryptography, Springer-Verlag, 2000, 

pp. 46-57. 

C. European Parliament, Directive 2000/31/ec of the european parlia- 

ment and of the council of 8 june 2000 on certain legal aspects of 

information society services, in particular electronic commerce, in the 

internal market ("directive on electronic commerce”), Official journal 1 

178 17/07/2000 p. 0001 - 0016. 

J. L. Ferrer-Gomila, A. M. Nadal, M. Payeras-Capella, L. H. i. Rotger, 

A juridical validation of a contract signing protocol, in: EC-WEB *02: 

Proceedings of the Third International Conference on E-Commerce and 

Web Technologies, Springer-Verlag, 2002, pp. 343-352. 


[3] 


and 


(8) 


non-repudiation, 
(1997) 267-281. 


[5] 


[6] 


[9] 


[10] 


111] 


On Commitment Schemes Based on Logarithmic 
Signatures 


Pedro Taborda Duarte 
Dpto. de Matemática Aplicada 
Universidad Rey Juan Carlos 
C/ Tulipán s/n. 28933, Móstoles, Madrid, Spain 
Email: pedro.duarte Ourjc.es 


Abstract—We consider commitment schemes and covers de- 
fined over a non abelian finite group, and propose some lines 
towards a construction of an unconditionally binding — com- 
putationally hiding commitment scheme based on a logarithmic 
signature. 


IT. INTRODUCTION 


After the advent of public key cryptography, the vast 
majority of the proposed protocols were based in number 
theory problems i.e. security would follow from the hardness 
of solving a certain number theoretic problem. But quantum 
computing and Shor's algorithms put a date on until when we 
are unable to solve these number theoretic problems. Hence, 
research on new computational problems not based un num- 
ber theory, became important. Recently, some cryptographic 
protocols were proposed in the area of group theory, using 
certain factorization sequences (called logarithmic signatures) 
present in the platform group, where security follows from the 
assumption that these sequences induce hard factorizations. 
Some protocols have been proposed using this primitive e.g. 
MST, [11], MST) [11] and MST; [8], [12] as well as some 
cryptanalysis [1], [2], [5], [6]. 

In this work we focus on cryptographic protocols called 
commitment schemes which can be seen as a generalization 
of encryption schemes. Important examples of commitment 
schemes include Pedersen's [13] — one of the fastest and 
most used commitment scheme and based on the well studied 
discrete logarithmic problem, ElGamal's [4] — one of the sim- 
plest and based on the decisional Diffie-Hellman problem, and 
Groth's [7] — one of the most recent ones, very efficient and 
based on a not so standard computational problem/assumption 
called the simultaneous triple pairing assumption. 

We propose some lines on how to construct a commitment 
scheme based on a logarithmic signature in a group, and 
moreover, committing to group elements. With this, one does 
not need to convert the committed element to bit strings, as 
one can, for example, commit to a permutation T € S,, as an 
ordering of an n—set. 


TI. COMMITMENT SCHEMES 


Commitment schemes are protocols between two parties in 
which one of the players (the prover-P) chooses a message m 
from some (finite) set, and releases some information m; to 


the other player (the verifier-V). Later, P may release more 
information ma to V so that he may open this commitment 
and learn m. Typically, m;, is some form of m in disguise and 
ma allows to fully reconstruct m from m:. 

An example of a commitment scheme's application are 
sealed-bid auctions. With it, we achieve secrecy and unam- 
biguity: secrecy to the participants, because the auctioneer 
cannot learn what is the bid without the bidder”s private key 
(since the bid is locked in a hard to break into safe), making the 
bid secret until the end of the bidding phase; and unambiguity 
to the auctioneer because no bidder will be able to change 
his bid after seeing a previously disclosed opponent's bid (the 
auctioneer first collects all the safes). The simple functionality 
of commitment schemes enables the construction of secure 
protocols that accomplish surprisingly complicated tasks as 
for example, solving the so called coin flipping by telephone 
problem!. 


A commitment scheme typically has three parts: a genera- 
tion key algorithm, a commitment algorithm, and an opening 
algorithm, along with an initial setup of entities where the 
protocol bases itself. More precisely, 


+. The key generation algorithm pk — Gen 

. The commitment algorithm Commit : MXxR=>CxD, 
where M stands for the message space, R for the space 
from where P introduces randomness into the commit- 
ment, C the image space for the commitment values, and 
D the space of the decommitment values ¡.e the keys that 
will allow V to “open the box”. Most of the times the 
decommitment values will be of the form d = (m,r) 
where m € M is the committed value and r € R the 
randomness and we will most often not make explicit d 
when presenting a commitment scheme. 

. The decommiting algorithm Open : CxD=>.MU(L(L1]. 
Open will output either an m € M if it is presented with 
a correct commitment/decommitment pair (c,d) € CXD, 
or 1 if not 1.e if P doesn't provide V with the correct 
decommiting value d that correctly corresponds to the 
message m to which the committed value c is attached. 


Two basic properties are therefore essential in any commitment 
scheme: P should not be able to change his mind after 


ISee [3] for details 
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committing to a value, and V should not be able to learn about 
the message committed to. These two properties are referred to 
as the binding property and the hiding property. The former 
ensures fairness to the verifier and the later fairness to the 
prover. 

As in many cryptographic applications, security is based 
not on an impossibility to break some assumption, but rather 
on the difficulty to break it. Therefore, regarding the binding 
and hiding properties, two flavors are considered: uncondi- 
tional and computational. Informally, a commitment scheme is 
computational (resp. unconditional) hiding if any polynomially 
bounded verifier (resp. any verifier, no matter how powerful) 
has at most a negligible advantage in finding the committed 
value (over making a random guess). Computational (resp. 
unconditional) binding on the other hand means that a poly- 
nomially bounded prover (resp. any prover, no matter how 
powerful), has at most a negligible chance of finding two 
different messages that commit to the same value. 


Definition 1.1. e(1) is negligible in 1 if for any polynomial 
F, ell) <1/£(0) for all large enough | 


Definition 11.2. Hiding: A commitment scheme is (t, e)-hiding 
if any t-time adversary A = (A1, Az) achieves advantage 


pk += Gen(1' ), 

s (0,1), 

(moy, m1,0) — Ar (pk), - 
(c, d)  Commitpr(ms, Ts) 

: A2lo,c) =s 


1) If t is not infinite i.e if the adversary is polynomially 
bounded and the advantage is negligible in the length 
of the input, the scheme is said to be computationally 
hiding 

2) If the adversary is infinitely powerful but the advantage 
is negligible in the length of the input, the scheme is 
said to be statistically hiding 

3) If the adversary is infinitely powerful and the advantage 
is null, the scheme is said to be perfectly hiding 

4) The scheme is said to be unconditionally hiding if it is 
perfectly hiding or statistically hiding. 


Pr 


Definition 11.3. Binding: A commitment scheme is (t,e)- 
binding if any t-time adversary A achieves advantage 


pk <= Gen(1' ), 

(c, do, d1) — A(pk) 

: 14 0Openpr(c, de) A 

LH Openpr(c, d1) A 

Openpr(c, do) 4 Openpr(c, d1) 

1) If t is not infinite i.e if the adversary is polynomially 
bounded and the advantage is negligible in the length 
of the input, we speak of computationally binding 

2) If the adversary is infinitely powerful but the advantage 
is negligible in the length of the input, the scheme is 
said to be statistically binding 

3) If the adversary is infinitely powerful and the advantage 
is null, we speak of perfectly binding 


Pr < ell) 


4) The scheme is said to be unconditionally binding if it is 
perfectly hiding or statistically binding. 


It thus seems that one should aim at building commitment 
schemes which are both unconditionally hiding and uncondi- 
tionally binding. Unfortunately, in a two-party commitment 
scheme, this is impossible: a compromise must be made 
(see [3]). The main reason for this is that each player sees 
everything the other party sends. However, in a multi-party 
scenario, or in a two party case where communication is 
noisy, it is no longer true that each player sees everything 
the other party sends, and in these cases it is in fact possible 
to obtain unconditionally hiding and unconditionally binding 
commitment schemes. 


It can also be proved that, 1f a commitment scheme is 
unconditionally binding but its output does not depend on the 
random parameter, then the scheme cannot be computationally 
hiding. Hence, in building commitment schemes it is crucial 
to introduce randomness into the commitment. 


TII. COVERS AND LOGARITHMIC SIGNATURES 


Most of the well-known public-key cryptosystems which 
are still unbroken are based on certain intractable problems 
in large finite abelian groups, such as the multiplicative group 
of units in the ring Z,¿ with p, q primes, the multiplicative 
group of a finite field, or a cyclic subgroup of the group of 
rational points of an elliptic curve over a finite field. 

One of the first symmetric-key cryptosystems exploiting 
the structure of non abelian groups was proposed by Magliv- 
eras [9] and was named PGM. It explicitly used a special 
type of factorization in non abelian permutation groups called 
logarithmic signatures, and later the ideas behind it were 
used in [11] to design the asymmetric schemes M5ST, and 
MST,. There are instances using finite groups where it is 
possible to build a logarithmic signature such that the in- 
tractability of solving the discrete logarithmic problem implies 
the intractability of factoring with respect to the logarithmic 
signature involved. The idea on using these objects as a tool 
for building secure cryptosystems, is the assumption of the 
difficulty to factor elements of the group with respect to 
the used logarithmic signature. Nevertheless, in subsequent 
works [2], [6] [2]the assumption of hardness of factoring with 
respect to a logarithmic signature in these protocols proved to 
be rather unrealistic by showing that it is unclear on how to 
generate computationally hard to invert logarithmic signatures 
for (almost) all group elements. In this work we explore 
whether they can be useful for designing another cryptographic 
tool, that of commitment schemes. 


A. Definitions and some results 


Let G be a finite group and for each ¿ = 1,...,s take 
os = [051,...,Qr, € G and S € Ga set. Write 
a=Ía1,..., Qs). 


Definition 1.1. Cover and Logarithmic Signature 
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1) Cover: a is said to be a cover for S if any element 
g € S can be written as a product 


9 = Ali --« Asi, (IIFA.1) 


The vector (ri,...,Ts) is called the type of the cover 
and l =r, +...+"rs is length. 

2) Logarithmic Signature: Let o: be a cover for S and let 
g E S. If the decomposition (HI-A.1) is unique, a: is 
said to be a logarithmic signature for S 


Let a as in definition IH.1 be a cover of type (r1,... 
for G and let m =][;_, r;. Consider the mappings 


,Ts) 


A: 0: O0Lr, — Lm 


s 1-1 
(kz, .-.,ks) =D (%i ] [ 75) 
i=1 j=1 
and 
da: Zo, O0:::90ZL,, —>G6 
(ka, ks) — 01h, ->-Qnk, 


Both these mapping are easily seen to be injective and 
moreover there is an efficient algorithm for computing A7?. 
Therefore we are able to efficiently compute ? 4= 0, 0 A7! : 
Dim > G. 


Example 111.2 (Computation of 4). This is an example taken 
from [S] and exemplifies the computation of ú: in the alternat- 
ing group As. In table I each row of the left column represents 
a block of a. Let also AMa¡ 1= 1,...,3 be represented by each 
row from the right column in table I. 


Then it is easy to check that M, = [|Ma1,Aa2, Aa3] is a 
logarithmic signature for the additive group Ze. Because 
lAs| = 60 we wish to compute 4 : Zo) —> As on an 


element x € Zgy. Such an x can be uniquely written as a sum 
of elements from A, by using a greedy selection algorithm 
for each component, sequentially from the bottom block up- 
wards. This essentially determines Ax) = (51,52, j3) with 
Ji € Mai E Ly, ri = Mail € (3,4,5) and by retrieving the 
associated element x; € a of j¡ we then set Á(t) = 11:12:03. 


If x= 47 then x is written uniquely as 47 =2+9-+36 and 
we are looking for (j1,32,j3) € La x La x Ls such that 
4=J:1+3.:3+33 : 12. It is immediate then to verify 
that it must be A(2,3,3) = 47. Therefore, by inspection on 
the table, we get that 


6(47) = Q1 209 303 3 
=  (1)02)854) - (1)(43)(5) - (13)(2)(45) 
= (123) 


| 


Two logarithmic signatures o, and P for G are said to be 
equivalent if 4 = P. We now define what is meant by “hard to 


21f a is a logarithmic signature m = |G| 


Q Aa 
A; Zoo 
(10)G45) 0 
(1006)6534) 1 
03866) 2 
(10 314 5) 0 
(10O534) 3 
(O 4 316) 6 
0366) 9 
(02466) 0 
(DO 3 514) 12 
(134 5) 24 
(15342) 36 
(14325) 48 
TABLE I 
LOGARITHMIC SIGNATURE (Y AND CANONICAL LOGARITHMIC SIGNATURE 
Aa 


factor” and “easy to factor” covers (or logarithmic signatures. 
See also [10]. 


Definition (IL3. Let G be a finite group of degree n and a 
a cover for G?. 
1) a is said to be tame if there exists a ppt algorithm A 
such that Ala, g) € 47*(g) for any y € G 


¡.e if with overwhelming probability, A outputs one of 
the several factorizations HI-A.lI of element y 

2) Q is said to be wild if it is not tame 
¡.e if any ppt algorithm A, has negligible probability in 
outputting a factorization of a random y € G 


Given a cover q and an element yg € G, to find one 
w € 47(g) it is necessary to obtain any of the possible 
s-tuples (i1,...,is) such that g = Q%1;, ...On¡, and then 
compute x = A(i],...,2s). This is possible if and only if 
a. is tame. Nevertheless, there are instances where obtaining 
this factorization is indeed believed to be hard: 


Example !L4. In the class G of finite groups, there are 
instances (G,0) with a: a cover, where the factorization 
in (IIFA.1) is equivalent to solving the discrete logarithmic 
problem in G. 

Proof: Take the finite field 1, and consider its multiplica- 
tive group G = IE, on which the discrete logarithm problem 
is believed to be hard. Suppose l is the least positive integer 
such that 271 < |G| < 2!, let g € G be a generator, and 
consider the set a. = [a1,...,01] with a; = (1,9273. Then 
a. is a cover * for G and moreover, factorization with respect 
to a. amounts to solving the discrete logarithm problem in G. 

[tal 


Example TLS. /n the (infinite) group of n-braids B,, with 
generators 403,...,0n-—1) it can be proved that the elements 


As = (0-1 ds 0i+1)0% (A mo ai)” 


3In [11] the authors proposed a public-key cryptosystem MST, whose 
security is precisely based on the computational difficulty of inverting 4 when 
a. is a logarithmic signature 

4We take S = G although everything can be translated to the case S CG 

5a is called a 1-quasi-logarithmic signature. See e.g. [11] 
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for1< i< j < n generate the subgroup P,, of pure 
braids, and that for each i € [1,...,n— 1), the set G; = 
[Asi+1>»-.» Ainy is a free set of generators of a subgroup of 
P,, which is isomorphic to the free group F,,-;. Artin showed 
that any pure braid P € P,, can be written uniquely as a 
product 


B =C1C2***Cn-1 


where each c; is a unique reduced word in the generators of 
G; and their inverses. More precisely, Artin showed that 


Pa = Ppn-1 A (F,-2 0" (Pa x F,)) 
The normal form of this iterated semidirect product is called 
Artin's combing of pure braids. 


We can therefore generate a logarithmic signature a of type 
(r1,...,?n-—1) for S € Ps, by setting 


055 ES Árigt; >>.» Ain > 


fori=1,...,n-1landj=1,...,r;. 


Remark IIL6. Al! known algorithms for combing a random 
pure braid B written in the generators A, and their inverses, 
are not polynomial in general in the length of 8 and hence we 
may assume that a. is wild in S. Nevertheless, since Cp-1 € 
(AR e) it is always feasible to find the last block c,,-1 of 


n—1,n 


B. 


IV. A COMMITMENT SCHEME BASED ON A LOGARITHMIC 
SIGNATURE 


We propose a commitment scheme in the line of group 
theory based cryptography. The scheme”s security is based on 
the hardness of solving a certain problem in a group theoretic 
setting and commitments are made to group elements not 
integers/bits. More precisely, for its construction we use a 
public, hard to invert logarithmic signature over a finite group 
G, and a public general function H : (Z¡q¡)? => G. The 
use of a logarithmic signature «+ and its unique factorization 
property implies almost immediately that the scheme is 
unconditionally binding. Computational hiding follows if H 
1s such that a certain decisional problem - involving a: and HA 
- On the base group is hard (definition IV. 1). It is a decisional 
problem related to computational indistinguishability of group 
elements á4 la decisional Diffie-Hellman problem. If this 
problem is hard we call G a DLSg— group. 


Let G be a group, and a = [a1,...,0s] with a; = 
[a 51,.--,Qir,j, 1< 1 <s a logarithmic signature for G. 
If g = á(x) = 01%, :::Onx, we write Bl;(g) = Qíx, 1 = 
Mis 

Note that [[;_,r, = |G| because «a: is a logarithmic 
signature. As the security parameter we take the Log of the 
order of Gi.e. 1 =gef Log|G| 


Definition 1V.1. (A-Decisional) Let H : (Z¡q¡)? => G be 
some function. G is said to be a DLSy — group if for any 


efficient algorithm B, the modulus of the difference between 


Pri(e!,...,2%) a (Z¡G¡)* : 


B((4(20),...,4(x*)), H(x!,...,x2*)) =1] 
and 
Prile?,...,27) re (Ziay?,h =r G 
B((a(x"),...,á4(x*)),h) =1] 


is negligible in the security parameter l. This quantity is 


denoted Advy(B). 


A. The Scheme 


Let H : (Z¡a¡)? > G be a function, and consider the 
following commitment scheme where the prover P commits 
to an element y € G and sends the commitment to a verifier 
V. We can describe it the following way: 

Gen(1') 

1) Generates a logarithmic signature o 
2) Generates a function H : (Z¡c¡)* > G 
3) Publishes pk = (a, H) 
Commit 
To commit to y € G, 


1) P chooses u.a.r an s-tuple oia) € 
(Zia¡)* 
2) P computes cy = g- H(x!,...,x2*) and cz = 


(á(a0),..., (xs) 
3) P sends V the pair (c,c2) 
Open 
1) P sends the committed element y and the ran- 
domness (x*,...,1*) to V 
2) V checks P”s computations and outputs “ac- 
cept” if they are correct or L if not 
The following result immediately follows from the uniqueness 
of factoring through a: 


Proposition 1V.2. If a is a logarithmic signature for G then 
the commitment scheme described above is unconditionally 
binding. 

Proof: If the prover can find (g0,(x*,... 
(91,(y!,...,y*)) such that 


,23)) and 


Commigo, (2*,...,x*)) =Comm(g1,(y!,...,y*)) 


then 6(x*%) = (y?) for all i=1,...,s, and 


90 a) Al cl 
Since a. is a logarithmic signature we get x* = y! for all 
1=1,...,s, and therefore gy = 91. ug 


Proposition 1V.3. If (G isa DLSy — group then the 
commitment scheme is computationally hiding. 

Proof: The following is the original hiding game between 
an adversary A and the challenger (see figure 1): 
GAME 0 


1) A chooses and sends the challenger a pair (g%, g*) € G? 
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2 


— 


The challenger randomly chooses a bit b and keeps it 

(i.e does not disclose it to A) 

The challenger randomly chooses (x!,.. 

(Z¡6¡)* and sets cz = (á(a?),... : 0) 

4) The challenger sets cy = yg? - H(x?,...,2*) 

5) The challenger sends A the pair (cz, ca) 

6) A outputs a bit b 

Letting So be the event that b = bi 
riS 
n l. 


3 


= 


A 


in GAME 0, the 
adversary's advantage is Adv(A) = |Pr[Sp] — 1/2l. A wins 


the game if Adv(A) is non negligible in 


We now make one small change to GAME 0 by computing cz 
as 9 - h for a randomly chosen h € G (see figure 2): 


(9%, 9*) = A 
b —R (0, 1) 
(a, 25) —R (Zi)? 
C1 e  g-Híe,...,x*) 
Ca = ¡Me la. ale”) 
b —= A(c;,ca) 

Fig. l.. GAMEO 


GAME 1 


1) A chooses and sends the challenger a pair (9%, y!) € G? 
2) The challenger randomly chooses a bit b and keeps it 
(i.e does not disclose it to A) 

The challenger randomly chooses (x!,... 
(Z¡6¡)? and sets cs =(ú(a?),..., 4(a*)) 

The challenger randomly chooses h in G and sets c1 = 
g-h 

5) The challenger sends A the pair (c,,c2) 

6) A outputs a bit b 


3 


= 


23) in 


4 


= 


(9%, 9”) “ A 
b <—R (0, 1) 
h <—R G 
(es, 87) —R (Ziay)* 
C1 _= g' «Rh 
Ca =  (á(z*),...,á(.*)) 
b + A(c;,c2) 
Fig. 2. GAME l 


Let S be the event that b= b in GAME 1. 


Claim 1. Pr[S,] = 1/2. This follows from the fact that on 
this game, the view of the adversary is independent from b. 

Claim 2. Adv(A) = Adup(B) is negligible. This 
follows from claim 1. and from observing that in 
Game 0 the pair (cr, ca) is essentially of the form 
((á(xb),... ,á(o 7) H(x!,...,1*)) while in Game 1 it is of 
the form ((G(x1),...,(4(x3)), h). To be more precise, consider 


the following algorithm B on input ((w!,...,w*),h) € G* x 
G (see figure 3): 

1) A chooses and sends B a pair (9%, 9!) € G? 

2) B chooses a random bit b and keeps it (i.e does not 


disclose it to A) 


3) B computes c; = g* - h, sets co = (w!,...,w*), and 
sends the pair (c1,c2) to A 
4) A decides and sends B a bit b 
5) Ifb=b then B outputs 1, else outputs O 
B((w!,...,ws), Ah): 
(9%, 9) - A 
b —R (0, 1) 
C1 += g -h 
Ca E CA 
17) += Aci, Ca) 
IF b= THEN Output 1 
ELSE Output 0 
Fig. 3. 
Ffh=Hle?,...,22) with wi =á4(1%) (i=1,...,s) then 
computation proceeds as in GAME 0 and therefore 
CA a 
B((ó(a*),...,a(25)), H(el,...,20) =1) 
= Pr[So] 


Else it proceeds as in GAME 1 and therefore 


Pritel,...,a) na (Zip? herG: 
B((á(x*),...,4(x*)),h) =1] 
= Pr[Si] 
=1/2 


Hence Adv(A) =|Pr[So] — Pr[S¡]| = Advg(B). Therefore, 
under the DLSyg assumption, the commitment scheme is 
computationally hiding . m 


V. CONCLUSION 


We presented a proposal of a commitment scheme using 
logarithmic signatures. A logarithmic signature for which the 
problem of inverting it is hard, provides on its own an idea of 
computational hiding and perfect binding. The problem is that, 
using directly the logarithmic signature a: (more precisely: the 
special function á: from the ring Z¡a, to G associated with 
a. It is this function which is assumed to be hard to invert) it 
appears we would end up having to commit to strings of bits. 
One of the objectives here is to build a commitment scheme 
where the space of messages is a space of elements from a 
group and not bitwise. Next step in this line of research would 
perhaps revolve around finding a sufficient condition on the 
logarithmic signature so as to imply the hardness of the DLSy 
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problem (since wildness of a is a necessary condition), or 
methods for efficiently generating hard to factor logarithmic 
signatures on G. We feel that logarithmic signatures are 
a primitive with a large potential and can, in the line of 
research around group theory based cryptography, pose several 
interesting problems. 
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Abstract—Uno de los pasos más importantes en los procesos de 
voto electrónico es la firma digital de la lista de votos descifrados, 
dado que a partir de estos votos se podrán realizar recuentos 
paralelos para asegurar la validez del resultado de la elección. 
Para ello, un posible escenario consiste en que los miembros 
de la Mesa Electoral generen los parámetros de la firma y la 
ejecuten de forma distribuida. En este artículo proponemos una 
implementación robusta y eficiente de la generación distribuida 
de los parámetros RSA y de la firma RSA distribuida. 


I. INTRODUCCIÓN 


Hoy en día, el uso de las nuevas tecnologías en los procesos 
electorales es cada vez más común, dadas las numerosas 
ventajas que proporcionan. La gestión electrónica de unas elec- 
ciones permite obtener los resultados finales más rápidamente 
y realizar un recuento más preciso que si se hiciera a mano. 
Además permite incorporar dispositivos o métodos especiales 
que faciliten el ejercicio de su derecho a voto a personas 
mayores o a discapacitados. En el caso de que se realicen 
de forma remota, por ejemplo por Internet, los votantes que 
están en el extranjero en el momento de las elecciones pueden 
votar de una forma más cómoda y segura que mediante el voto 
postal. 

Sin embargo, la introducción de procesos lógicos que eje- 
cutan los diferentes pasos del proceso electoral proporciona 
nuevos desafíos a la hora de asegurar la validez del resultado 
de las elecciones. Existen varios requisitos de seguridad que 
una elección electrónica debe cumplir para ser como mínimo 
tan fiable como una elección convencional, como la autentici- 
dad y privacidad de los votantes, la precisión de los resultados 
de la elección, la verificabilidad del proceso electoral, etc. 

Para cumplir algunos de estos requisitos de seguridad es 
frecuente utilizar herramientas criptográficas estándar como el 
cifrado y la firma digital de los votos. 

En un esquema básico de voto electrónico utilizando estas 
herramientas, los votantes cifran sus votos en el momento de 
su emisión y los firman digitalmente usando sus credenciales 
(por ejemplo el DNIe). Al finalizar la fase de votación, estas 
firmas se verifican y se separan de los votos cifrados, que 
pasan por un algoritmo de anonimización (para desconectarlos 
de la identidad de sus emisores) antes de ser descifrados para 
realizar el recuento y obtener los resultados. 

El cifrado de los votos en el momento de su emisión permite 
preservar la privacidad del votante, ya que un atacante externo 
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que acceda al voto emitido por un votante no podrá descubrir 
el texto en claro y, por tanto, las opciones de voto que ha 
escogido. La firma digital permite verificar la integridad del 
voto (cifrado) e identificar a su autor mediante su certificado 
digital, comprobando que está en el censo electoral. 

Uno de los procesos cuya verificación es más importante 
en una elección es el correcto recuento de los votos. En 
una elección llevada a cabo por medios electrónicos esta 
verificación se realiza de forma similar que en una elección 
convencional: realizando un recuento paralelo. Es importante 
asegurar que el conjunto de votos sobre los que se realiza el 
recuento, es decir, los votos descifrados al final del proceso 
electoral, es auténtico y no ha sido modificado por ningún 
intruso malicioso. Para asegurar la integridad de la lista de 
votos descifrados, ésta se firma digitalmente. 


Firma digital. Una firma digital [Sch07] es una herramienta 
criptográfica que se utiliza para demostrar el origen y la 
integridad de un mensaje. Así, la validación de una firma 
digital permite al receptor comprobar que el mensaje ha sido 
creado por un emisor determinado (autenticidad) y que el 
mensaje no ha sido alterado durante su tránsito (integridad). 
Esto puede acometerse con diversos niveles de seguridad. El 
más exigente de ellos determina que un adversario no puede 
generar una firma válida para cualquier mensaje aún teniendo 
a su disposición la firma de cualquier otro mensaje que haya 
escogido él mismo. Esta noción de seguridad se conoce como 
no falsificación existencial bajo ataque con mensaje escogido 
adaptativamente - en inglés, Existential Unforgeability against 
adaptive Chosen Message Attacks, (EUF-CMA) [GMR88]. 

En términos generales un esquema de firma digital debe 
disponer de dos protocolos, uno para generar la firma y otro 
para verificar su validez. Cuando se usan algoritmos de clave 
pública para firmar digitalmente un mensaje, normalmente se 
calcula una función de Hash sobre éste, que es la que se firma. 


Firma digital con RSA. Uno de los algoritmos crip- 
tográficos de clave pública más utilizados en las firmas 
digitales, y en el que nos centraremos en este artículo, es 
RSA [RSA78], dado su amplio uso, su estandarización y 
la posibilidad de utilizarlo conjuntamente con certificados 
digitales. 

Dados unos parámetros RSA N, e y d, firmar un mensaje M 
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consiste, simplemente, en realizar la exponenciación modular: 


Sign(m, d) =m* mod N 


donde m = H(M) es el Hash mensaje a firmar, d es la clave 
privada y N = pq es el producto de dos primos de gran tamaño 
(del orden de 1024 bits cada uno). 

Para verificar dicha firma basta con calcular el Hash del 
mensaje recibido y compararlo con el resultado de otra expo- 
nenciación modular sobre la firma, esta vez usando la clave 
pública e del emisor: 


Verif(Sign(m, d), e) = (m*%)* mod N = mmod N 


La Mesa Electoral es el organismo que cuenta con mayor 
confianza en un proceso electoral. Este organismo posee las 
claves más importantes de la elección: la clave para descifrar 
los votos y la clave para firmar la lista de votos descifrados. 
Dado que algún miembro de la mesa electoral podría actuar 
de forma fraudulenta, una práctica habitual es utilizar un 
esquema de compartición de secretos para dividir y repartir las 
claves entre todos los miembros, de forma que únicamente los 
subconjuntos autorizados pueden reconstruirlas para descifrar 
O firmar de forma distribuida un documento. 

Esquemas de compartición de secretos. Los esquemas 
de compartición de secretos tienen como objetivo la división 
de un secreto en fragmentos de modo que sólo los conjuntos 
autorizados de usuarios pueden reconstruir el secreto. Cuando 
se aplica un esquema umbral a estos métodos, el resultado es 
que se necesitan un mínimo de fragmentos (el umbral) para 
reconstruir el secreto. Si uno de los poseedores de un frag- 
mento no quiere o no puede participar en la reconstrucción, el 
secreto se puede reconstruir a partir del resto de fragmentos 
(si llegan al umbral). 

En 1979, Adi Shamir [Sha79] publicó un método para 
compartir secretos con una estructura de acceso que sigue 
un esquema de umbral. Su protocolo se basa en generar un 
polinomio cuyos coeficientes se eligen de manera aleatoria, 
independiente y uniforme en Z¿ (con q primo): 


p(x) =d+ajr +01 +- + aj at? 


donde d es el valor secreto a compartir. El esquema puede 
modificarse para compartir valores secretos en otro anillo (por 
ejemplo, Z y). 

Una vez creado el polinomio, cada usuario recibirá un par 
(i, d;) donde ¿ es el identificador único de dicho usuario 
(típicamente: 1,2,...,n) y d; = p(i) es su fragmento del se- 
creto. Por otra parte, el grado de p(x) determina el umbral del 
esquema de acceso dado que se requieren + evaluaciones de un 
polinomio de grado t— 1 para determinar éste unívocamente. 
La recuperación del secreto puede hacerse usando los coefi- 
cientes de Lagrange: 


d=p(0) = Y d,Aj 
1€S 
donde S es un conjunto de t usuarios y A?, los coeficientes 


de Lagrange, cumplen A? = [| Pi 
JES 


A. Firma RSA distribuida 


Dada una clave secreta d compartida con un esquema de 
umbral en Zy, cada usuario puede utilizar su fragmento d; 
de la clave para realizar una firma parcial del documento, 
s; = m%, La firma m” puede reconstruirse a posteriori con 
tan sólo t firmas parciales s, y sin necesidad de reconstruir 
explícitamente la clave d. 


Los sistemas de compartición de secretos basan su seguridad 
en el hecho de que no se puede reconstruir la clave sin 
disponer de un número mínimo de fragmentos. Sin embargo, 
esta clave ha existido en algún momento antes de distribuir 
los fragmentos. Para prevenir la posibilidad de que alguien 
pueda acceder a ella antes de ser destruida, se pueden utilizar 
algoritmos que generan de forma distribuida los fragmentos sin 
necesidad de calcular la clave previamente. Estos algoritmos, 
sin embargo, requieren un gran intercambio de información 
para garantizar que los cálculos se realizan correctamente. Para 
ello disponemos de los esquemas de compromiso, que son una 
primitiva criptográfica de gran importancia en el ámbito de la 
computación distribuida. 


Compromisos de Pedersen. En [Ped91] se presenta un 
esquema de compromiso orientado a la verificación de se- 
cretos compartidos. Dicho esquema permite comprometer un 
mensaje antes de enviarlo para que el receptor pueda estar 
seguro de que dicho mensaje no se modificará a posteriori. 
Así mismo, el emisor del compromiso puede demostrar que 
todo los fragmentos enviados han sido calculados de acuerdo 
con el esquema de compartición de secretos acordado y son 
coherentes entre sí. 

Para comprometer un valor x € Z, se genera un elemento 
aleatorizador r Ep Z, y se calcula: 


com(x,r) = g"h" mod p 


donde y € Z, es un generador del subgrupo de orden q de Z; 
(con p y q primos de gran tamaño tales que q divide p— 1) y 
h = g” para algún y desconocido por los todos usuarios. 

Para abrir un compromiso de Pedersen es preciso hacer 
públicos los valores x y r. Sin embargo, disponemos de otras 
primitivas, las pruebas de conocimiento cero, que nos permiten 
demostrar que se conocen dichos valores sin necesidad de 
revelarlos. En [DF02] Damgárd y Fujisaki propusieron una 
versión de los compromisos de Pedersen que es apta para 
comprometer valores de Z y que es la que usamos en nuestra 
implementación. 
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B. Generación distribuida de parámetros RSA 


Los sistemas de generación distribuida de parámetros RSA 
basan su funcionamiento en la búsqueda de un número pro- 
ducto de dos primos a partir de fragmentos aportados por 
todos los participantes en el protocolo. Una vez encontrado 
este número, se crean a partir de él los fragmentos de la 
clave privada (uno por cada participante) y se calcula la clave 
pública entre todos. 


En este artículo nos centraremos en la implementación 
práctica de la firma distribuida RSA de la lista de votos 
descifrados (por parte de los miembros de la Mesa Electoral) 
utilizando sistemas de compartición de secretos, y en la 
generación distribuida de los parámetros de la clave privada 
para realizar esta firma. 

El objetivo de esta implementación es obtener una solución 
que se pueda aplicar y utilizar en entornos reales y actuales, 
teniendo como punto de partida la literatura existente y el 
estado del arte, pero sin olvidar las condiciones del entorno en 
el que se utilizará. Dado que actualmente los componentes de 
la infraestructura de clave pública trabajan mayoritariamente 
con el criptosistema RSA (Autoridades Certificadoras, DNIe, 
etc), nos hemos decantado por el uso de este algoritmo en 
lugar de otros más ventajosos o eficientes, como DSA o 
algoritmos basados en la criptografía de curvas elípticas, cuya 
implantación no está aún debidamente extendida. 

Existen ciertos requisitos de seguridad y eficiencia que 
deben cumplirse en estas implementaciones. Por ejemplo, dado 
que se firma información muy sensible para la elección, el 
protocolo deberá ser robusto y seguro: un número de atacantes 
menor que el umbral de reconstrucción no debe ser capaz 
de impedir la generación de una firma distribuida correcta, 
ni averiguar información importante sobre los parámetros 
RSA generados de forma distribuida. También deberán poder 
ejecutarse en un tiempo razonable: no se debería exigir la 
disponibilidad de los miembros de la Mesa un día entero 
(por ejemplo) para generar los parámetros. La capacidad de 
firmar de forma distribuida un documento proporciona la 
posibilidad de que los miembros de la Mesa Electoral actúen 
de forma remota (si son de regiones lejanas o en caso de 
enfermedad). Así pues, sería conveniente que el protocolo de 
firma distribuida fuera lo menos interactivo posible para poder 
facilitar esta solución, ya que los participantes no tendrían que 
ir esperándose unos a otros, y podrían ejecutar el protocolo 
a diferentes horas. Finalmente, debemos considerar que una 
Mesa Electoral está formada por alrededor de 10 miembros. 

El artículo está estructurado de la siguiente forma: en la 
sección II se presenta una propuesta de implementación de 
un algoritmo de firma distribuida RSA y en la sección III se 
explica un método para la generación distribuida y robusta de 
un módulo RSA. 


TI. FIRMA DIGITAL DISTRIBUIDA 


Como se ha introducido anteriormente, la finalidad del 
sistema a implementar es firmar un documento de forma 
distribuida mediante una estructura de umbral. Para hacerlo, 


cada firmante dispondrá de un fragmento de la clave privada, 
que habrá sido repartida mediante un esquema de compartición 
de secretos. La manera de obtener dichos fragmentos se 
comentará en la sección II. Durante el proceso de firma, cada 
participante usa su fragmento para obtener una firma parcial 
que tendrá que ser verificada por los otros participantes. 

Una firma digital distribuida tiene ciertos requisitos que 
deberemos tener en cuenta a la hora de implementar nuestra 
solución: imposibilidad de falsificación (requisito heredado de 
la firma digital estándar) y robustez. El primer requisito im- 
plica que un grupo de participantes solamente puede firmar un 
mensaje si es un conjunto autorizado. En el caso de una firma 
de umbral, un conjunto está autorizado si contiene, al menos, 
un número determinado de participantes, por ejemplo, más de 
la mitad. La robustez del sistema es la propiedad que garantiza 
que, aunque algunos participantes sean maliciosos, se pueda 
obtener la firma del mensaje. Como requisito adicional, es 
interesante que se pueda detectar a los participantes que no 
hayan realizado correctamente el protocolo. 

Otra característica a tener en cuenta es la interactividad 
del sistema de firma digital distribuida. En la medida que 
sea posible, interesa que el protocolo sea no interactivo. De 
esta manera, cada participante puede hacer sus cálculos de 
manera independiente y no debe esperar datos de los otros 
participantes. 


A. Trabajo previo 


Shoup [Sho00] es el primero en proponer un esquema 
eficiente de firma de umbral RSA que es a la vez robusto y 
no interactivo. Como dice en su artículo, hasta ese momento 
solamente había sistemas que o eran interactivos, o no eran 
robustos o generaban firmas de tamaño excesivo. 

Para su esquema, Shoup utiliza un módulo RSA N producto 
de dos primos seguros p y q (decimos que p es un primo 
seguro si (p—1)/2 = p' también es primo). Para conseguir un 
protocolo no interactivo usa pruebas de conocimiento cero no 
interactivas, que resultan muy sencillas gracias a que p y q son 
primos seguros. El problema de esta propuesta reside en que 
la generación de un módulo RSA de estas características es 
mucho más complicada que la generación de un módulo RSA 
cualquiera (sin restricciones): si para encontrar un primo de k 
bits necesitamos examinar O(k) números, para encontrar un 
primo seguro del mismo tamaño necesitamos examinar O(k?) 
candidatos. 

Posteriormente, en 2005, Damgárd y Dupont [DDOS] pro- 
ponen un esquema de firma umbral RSA robusto, sin hipótesis 
añadidas y con un módulo RSA genérico. Sin embargo, 
no imponer restricciones al módulo RSA acarrea diversos 
inconvenientes. El primero de ellos es que las pruebas de 
conocimiento cero fallan con probabilidad no negligible y 
que, por lo tanto, es necesario reconstruir la firma diversas 
ocasiones (con diversas combinaciones de firmas parciales) 
para asegurar que el protocolo sea robusto y eficiente. El 
segundo es que las pruebas de conocimiento nulo, y por tanto 
el protocolo, pasan a ser interactivos. 
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Para que un esquema de firma umbral RSA sea robusto, el 
número de participantes maliciosos no puede ser demasiado 
grande. En concreto, si t es el número de participantes 
maliciosos y n el número de participantes en total, se tiene que 
cumplir que t < n/2. Este requisito es intuitivo: si queremos 
que los participantes maliciosos no puedan firmar un mensaje 
cualquiera (seguridad) y que si se los expulsa igualmente 
se pueda realizar la firma (robustez), entonces el número de 
participantes maliciosos tiene que ser menor que el número de 
participantes buenos. 


B. Nuestra implementación 


Para realizar nuestra implementación, partimos de la base 
que tenemos un módulo RSA al que no podemos imponer 
ninguna restricción. El objetivo es obtener una implementación 
robusta, segura y, a poder ser, no interactiva. 

Nuestro esquema se basa en el protocolo de Damgárd 
y Dupont [DDOS] realizando algunas modificaciones para 
explotar al máximo la idea de hacer distintas combinaciones 
en la fase de reconstrucción de la firma. En todos los artículos 
anteriormente citados, se da por supuesto que el número 
de participantes puede ser arbitrario y, en consecuencia, los 
autores trataban de hacer que la complejidad creciera con- 
troladamente con el número de participantes. En el escenario 
real en el que se centra nuestro trabajo tendremos un número 
reducido de participantes (alrededor de 10) y, por tanto, este 
factor no resulta tan determinante. 

En concreto, nuestra propuesta se basa en eliminar las 
pruebas de conocimiento cero (que fallan con probabilidad 
no negligible y son interactivas si se usa un módulo RSA 
cualquiera), consiguiendo un protocolo no interactivo y más 
efectivo que el esquema de [DDOS] en el escenario en que nos 
encontramos (alrededor de 10 participantes). Si bien es cierto 
que hay métodos para hacer pruebas de conocimiento cero no 
interactivas, el coste de éstas las hace impracticables si se usa 
un módulo RSA sin restricciones, como sucede en nuestro 
esquema. La robustez, que antes se derivaba de las pruebas 
de conocimiento cero, la conseguimos mediante repetidas 
reconstrucciones de la firma. A continuación justificamos por 
qué el esquema sigue siendo seguro y robusto. 

La seguridad es inmediata ya que no depende de las pruebas 
de conocimiento cero sino del esquema de compartición de 
secretos y el esquema de firma RSA estándar. 

Para justificar la robustez solamente se tiene que ver que 
el tiempo que tardaremos en obtener la firma correctamente 
es finito y razonable. Dada la restricción del número de parti- 
cipantes maliciosos, sabemos que al menos una combinación 
de las firmas parciales será correcta (aquella que provenga 
de participantes honestos). Por otra parte, en el peor de los 
casos contaremos con el máximo número de participantes 
maliciosos y la combinación correcta será la última de las 
que examinaremos. En total hay ( 21) maneras de combinar 
las firmas parciales para reconstruir la firma. En la Tabla 1 
se expone cuánto vale este número para distintos valores de n 
(participantes) y tomando t (participantes maliciosos) máxima 
tal que t < n—t. Si t no es máxima, entonces el número 


n | (7) 
213 
5 | 10 
8 | 56 
10 | 210 
12 | 792 
14 | 3003 


Tabla 1: Maneras de escoger t elementos entre n 


de combinaciones posibles es menor que el presentado en 
la Tabla TI. En conclusión, el número de combinaciones es 
razonable para los valores de n que se usarán en la práctica 
(aunque crece exponencialmente al aumentar n) y por lo tanto 
podemos obviar las pruebas de conocimiento cero y limitarnos 
a repetir la fase de reconstrucción hasta obtener una firma 
válida. Para reducir el número esperado de combinaciones 
necesarias para encontrar la correcta, se elige aleatoriamente 
el orden en el que se realizarán las reconstrucciones. De ese 
modo los participantes maliciosos no podrán forzar el caso 
peor. 

Por otra parte también se ha implementado una subrutina 
que se encarga de la detección de participantes malignos. En el 
protocolo de [Sho00] esta detección se realizaba en las pruebas 
de conocimiento cero. La solución que nosotros proponemos 
es sencilla y efectiva siempre que tengamos valores de n 
pequeños. Una vez obtenida la firma, basta con coger el 
conjunto de participantes honestos y sustituir un participante 
por otro que no esté en el conjunto. Si el participante nuevo 
fuera honesto, la firma resultante debería ser correcta, de no 
ser así el participante es malicioso. En total deberemos hacer 
n—t-—1 reconstrucciones extra, que se pueden reducir usando 
la información que se obtiene al intentar construir la firma. 


C. Resultados obtenidos 


El estudio teórico de nuestra implementación arroja los 
siguientes resultados. Como se puede ver en el artículo en 
que nos basamos [DDOS], para realizar una firma parcial cada 
participante tiene que hacer una sola exponenciación modular. 
Por otra parte, cada reconstrucción de la firma consta de dos 
pasos: primero se elevan las t + 1 firmas parciales a los coe- 
ficientes de Lagrange correspondientes y luego se multiplican 
entre ellas. Posteriormente se hacen dos exponenciaciones más 
para conseguir la firma y finalmente se comprueba que la firma 
es correcta, haciendo una última exponenciación. 

Dado que la firma parcial solamente se calcula una vez, 
se requieren t + 4 exponenciaciones que deberán repetirse 
hasta (5 veces. Aunque puede parecer un número grande 
(para n = 10 son cerca de 1700 exponenciaciones), todos los 
exponentes excepto el último son números pequeños, de unos 
45 bits, y en consecuencia las exponenciaciones son mucho 
más rápidas que con un exponente arbitrario de 2048 bits. Si 
comparamos nuestro esquema con el propuesto por Damgárd 
y Dupont, reducimos el número de operaciones en un factor 
de 10 (y conseguimos que el protocolo sea no-interactivo) en 
el escenario usual de 10 participantes y claves de 2048 bits. 

El resultado también se puede comparar con una firma RSA 
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estándar. En el caso de hacer una firma RSA distribuida el 
coste computacional es aproximadamente equivalente a una 
firma RSA estándar por cada firmante y, como máximo, ( Ani 
exponenciaciones equivalentes a una firma RSA estándar cada 
una realizadas por un usuario cualquiera para reconstruir la 
firma correcta. 

Como mejora adicional, los distintos participantes pueden 
hacer las reconstrucciones en paralelo a costa de perder la 
propiedad de no-interactividad del protocolo. En este caso 
el tiempo esperado se reduciría de manera proporcional al 
número de participantes honestos. 


TI. GENERACIÓN DISTRIBUIDA Y ROBUSTA DE UN 
MÓDULO RSA 


El protocolo de firma distribuida requiere la existencia de un 
módulo RSA (N = pg) y la distribución de su clave privada 
(d) entre los participantes siguiendo el esquema de acceso 
pertinente (en este caso, un esquema de umbral). 

En general, este punto se resuelve haciendo uso de una 
Tercera Parte de Confianza que genera el módulo RSA y la 
clave secreta y distribuye esta última adecuadamente. 

Existen, sin embargo, protocolos para la generación dis- 
tribuida de módulos RSA que permiten prescindir de la Tercera 
Parte de Confianza mejorando así la seguridad del sistema. Es 
por lo tanto interesante obtener un protocolo combinado de 
Generación y Firma que sea distribuido y robusto. 


A. Trabajo previo 


Todos los protocolos conocidos hasta la fecha para la 
generación distribuida de módulos RSA son fuertemente in- 
teractivos y, además, requieren un gran número de iteraciones 
para obtener un módulo válido. En consecuencia, la cantidad 
de cálculos adicionales que se necesitan para garantizar la 
robustez del protocolo los hace inviables en escenarios reales. 

En 1997 Boneh y Franklin [BF97] presentaron un proto- 
colo para generar módulos RSA de manera distribuida que 
era seguro contra adversarios pasivos, es decir, aquellos que 
siguen las especificaciones del protocolo pretendiendo obtener 
información de los participantes honestos. Sin embargo, no 
protege de adversarios activos, aquellos que no siguen las 
especificaciones del mismo. Lamentablemente este nivel de 
seguridad no concuerda con los estándares de robustez que se 
han aplicado al protocolo de firma (adversarios activos) y por 
lo tanto es necesario buscar otra alternativa. 

Un año después Frankel, MacKenzie y Yung [FMY98] 
ofrecieron una versión robusta de dicho protocolo que es, 
de hecho, la base de nuestra implementación. Su protocolo 
se compone de tres sub-protocolos, a saber, generación y 
multiplicación distribuida de p y q, test de biprimalidad y 
generación de la clave privada d. En ausencia de conductas 
maliciosas, las dos primeras partes se repiten una y otra vez 
hasta obtener un módulo RSA válido (NV = pq tal que p y q 
son primos) mientras que la última parte tan sólo se ejecuta una 
vez. Si, por el contrario, se detectan anomalías en el proceso se 
procede a identificar al causante (o los causantes) de dichas 


irregularidades para expulsarlos del proceso y se reinicia el 
protocolo. 

Posteriormente han aparecido diversas alternativas en este 
campo, como la propuesta de Algesheimer, Camenisch y 
Shoup [ACS02] y la de Damgárd y Mikkelsen [DM10], ambas 
más ineficientes que la presentada anteriormente. En el primer 
caso, la ineficiencia proviene de la necesidad de conseguir 
un módulo RSA formado por primos seguros. En el segundo 
caso, el test de primalidad de Miller-Rabin que se utiliza, aún 
finalizando en una única ronda, también es más ineficiente que 
[FMY98]. 


B. Nuestra implementación 


Como ya se ha mencionado, nuestra implementación se basa 
en el protocolo de Frankel et al. [FMY98] pero introduce algún 
cambio de cara a mejorar su eficiencia. 

En dicho protocolo cada participante elige dos números 
aleatorios p;, y qí y ejecuta un protocolo de multiplicación 
distribuida para obtener el valor de N = pq = Y p; + > Qi. 
Acto seguido se aplica un test distribuido de biprimalidad 
aprovechando la información de la que dispone cada usuario 
(pi, di y N). Este proceso de generación y chequeo se repite 
hasta obtener un módulo RSA válido (NV es producto de dos 
primos). La idea general consiste en usar una versión no 
robusta del protocolo por defecto durante la fase de prueba y 
error para encontrar el módulo adecuado y, cuando el módulo 
generado sea producto de dos primos, usar la versión robusta 
para garantizar que el protocolo se ha realizado correctamente. 

Una vez obtenido N se procede a calcular el valor de 
la clave secreta d para algún valor de la clave pública e 
acordado entre los participantes. En caso de que la clave 
pública no sea invertible el protocolo puede generar otra de 
manera automática. Al no disponer explícitamente de ¿(N), 
el sistema para determinar la invalidez de dicha clave pública 
es probabilístico pero el nivel de consumo de recursos que 
requiere es pequeño en comparación con el resto del protocolo. 
En nuestra implementación se sigue el sub-protocolo descrito 
en [FMY98] sin modificaciones. 

En [FMY98] la robustez se consigue eliminando a todo 
aquel usuario manifiestamente malicioso hasta que tan sólo 
queden participantes que sigan fielmente el protocolo. La 
detección de participantes maliciosos se consigue a través 
de un sistema de compromisos encadenados que parten de 
los fragmentos p; y q; y se actualizan en cada paso. Sin 
embargo, la fuerte interactividad y el volumen de cálculos 
que exigen dichos compromisos ralentiza el protocolo hasta 
hacerlo impracticable. 

Concretamente, cada valor que aparece en el protocolo debe 
ser comprometido antes de ser enviado para que aquellos 
que lo reciban puedan verificarlo y, si procede, comprobar 
que tanto el valor como el compromiso son coherentes con 
los compromisos previos. Este proceso de generación de 
compromisos y verificación es sumamente costoso ya que 
requiere cierta sincronización entre participantes y un gran 
volumen de comunicaciones. 
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Para evitar el desperdicio de recursos que supone generar, 
multiplicar y chequear la primalidad de p y q de manera 
robusta en los casos en los que estos valores no son primos se 
ha optado por modificar el protocolo de la siguiente manera. 

Se ejecuta la variante no-robusta del protocolo propuesta 
en [BF97] hasta finalizar el test de biprimalidad. Si el test 
da negativo los jugadores revelan los valores usados para 
que el resto de participantes pueda comprobar que, en efecto, 
N = Y p; q; y que p o q es compuesto. Estos cálculos 
pueden hacerse de manera local una vez recibidos los cor- 
respondientes fragmentos de p y q. En caso de que se 
detecte alguna anomalía se procederá a publicar la semilla del 
generador pseudo-aleatorio que ha usado cada participante de 
manera que los demás participantes puedan verificar, de nuevo 
localmente, que los elementos publicados por los demás han 
sido correctamente calculados. 

Si, por el contrario, el test da positivo, los participantes rea- 
lizan la versión robusta del mismo con los mismos parámetros 
iniciales (p;,, q;, semilla del generador pseudo-aleatorio, ...) 
para asegurarse de que todos los cálculos se han realizado 
correctamente sin tener que revelar ninguna información. 

En caso de que en algún punto se detecte una conducta 
fraudulenta iniciaremos un proceso de acusación que terminará 
con la expulsión del protocolo de todos los participantes 
que hayan mentido. Para ello, resulta imprescindible que los 
mensajes entre participantes vayan firmados, garantizando así 
su integridad y el no-repudio. Acto seguido se reiniciará el 
protocolo sin la presencia de dichos participantes. 

A pesar de que este último caso puede entorpecer el 
desarrollo del protocolo, ralentizándolo, no es necesario pre- 
ocuparse dado que sabemos que el número de participantes 
maliciosos no supera el 50% de participantes del sistema 
(típicamente menos de 5) y cada vez que se detecta a un 
usuario mintiendo se lo elimina inmediatamente, evitando así 
que vuelva a mentir. 

Además, en aquellos protocolos en los que todo compor- 
tamiento malicioso es detectado y en los que además se 
asegura la robustez, en el sentido de ser capaces de terminar 
aún en presencia de cierto número de participantes corruptos, 
un usuario no tiene ningún incentivo para intentar un ataque. 
Podemos esperar, por lo tanto, un comportamiento ideal por 
parte de todos los participantes. 


C. Resultados obtenidos 


El principal resultado obtenido por nuestra implementación 
ha sido hacer viable en un escenario real la generación 
distribuida y robusta del módulo RSA y de su clave privada. 
Se trata de un avance en el campo de las firmas distribuidas en 
procesos electorales que permite crear protocolos distribuidos 
y robustos sin necesidad de contar con una Tercera Parte de 
Confianza. 

En particular, dada la capacidad de nuestra implementación 
para detectar y eliminar participantes maliciosos inmediata- 
mente, la mayor parte del tiempo trabajaremos en régimen no 


robusto, reduciendo la complejidad de los cálculos necesarios. 
Además, la detección de participantes maliciosos es sencilla, 
pues basta con publicar los valores p, y q;, calcular localmente 
NY pi» qu y ver que coincide con el resultado obtenido en la 
multiplicación distribuida. Esto representa un coste añadido 
muy pequeño respecto al protocolo no robusto. 

Por otra parte, la eliminación de usuarios tampoco supone 
una reducción notable de eficiencia. El número de veces que 
se eliminan los usuarios es muy reducido comparado con el 
número de iteraciones necesarias para terminar el protocolo y, 
para comprobar quien ha mentido, se reproduce el protocolo 
localmente con las semillas de generador pseudo-aleatorio del 
cada participante. 

En resumen, con nuestra implementación se obtiene un 
sistema robusto y casi tan eficiente como las implementaciones 
del protocolo no robusto. Respecto al análisis de la compleji- 
dad del protocolo no robusto, remitimos al lector a [MWB99], 
donde se expone una implementación del protocolo no robusto 
y se analiza su eficiencia. La implementación realizada en 
[MWB99] consigue generar un módulo RSA de 2048 bits 
con 3 participantes en 18.13 minutos, un tiempo totalmente 
razonable. 
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Resumen—En España, la Constitución de 1978 reconoce (y 
la Ley Orgánica 3/1984, de 26 de marzo, regula) la denominada 
Iniciativa Legislativa Popular (ILP), consistente en un proceso en 
virtud del cual los ciudadanos pueden presentar proposiciones 
de ley suscritas por un número mínimo de firmantes. Con la 
aparición de los dispositivos de firma electrónica como el DNI 
electrónico, los procesos de ILP pueden llegar a sufrir una 
importante transformación puesto que la posibilidad de recogida 
de firmas digitales puede llegar a ser muy versátil. En este 
artículo se analiza, tanto desde el punto de vista técnico como 
el punto de vista jurídico, como la recogida de firmas mediante 
mecanismos digitales puede afectar a las ILP. 


Palabras clave: Iniciativa legislativa popular, firmas digitales, 
DNI electrónico. 


I.. INTRODUCCIÓN 


La Constitución Española, en su art. 87.3, prevé la partici- 
pación directa de los ciudadanos en el proceso de producción 
normativa, configurando al pueblo, mediante la presentación 
de 500.000 firmas, como sujeto de la iniciativa legislativa. 
Esta participación prevista constitucionalmente se encuentra 
regulada por la Ley Orgánica 3/1984, reguladora de la Ini- 
ciativa Legislativa Popular (ILP), que, tras ser modificada 
por la Ley Orgánica 4/2006, incorpora un nuevo art. 7.4, 
que establece, respecto de la naturaleza de las firmas, que 
“Las firmas se podrán recoger también como firma electrónica 
conforme a lo que establezca la legislación correspondiente”. 
La posibilidad de realizar recogidas de firmas electrónicas para 
ILP se confirma en la sesión de la Junta Electoral Central 
del 17 de septiembre de 2009. Por tanto, a la vista de lo 
expuesto, puede afirmarse que existe un marco legal que 
posibilita el desarrollo de una ILP a través de la recogida 
de firmas electrónicas. Cuestión distinta es la utilización que 
se haga en la práctica de esta posibilidad. 

Los trabajos realizados hasta la fecha en este campo no son 
demasiados y las iniciativas que han recogido sus firmas a 
través de medios digitales son escasas. 

Por un lado, encontramos distintas herramientas que per- 
miten la firma de documentos de forma telemática. De entre 
ellas, destacan CryptoApplet [2], ViaFirma [3] y Firma 
[4] que permiten la realización de firmas electrónicas en 
múltiples formatos así como su validación. En el marco de la 
administración electrónica, el proyecto Drupal X509 [5] ofrece 
un módulo para el gestor de contenidos Drupal que permite 
la creación de portales de participación ciudadana. El módulo 
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permite la creación de formularios y su firma utilizando el 
DNI electrónico. 

Sin embargo, estas herramientas están pensadas para la fir- 
ma de distintos documentos por varios usuarios, gestionándose 
dichas firmas de forma separada. Nótese que en una ILP, los 
condicionantes son distintos, puesto que se pretende realizar 
la firma digital sobre un único documento, la proposición, por 
múltiples usuarios. Además, la gestión de todas las firmas es 
una gestión conjunta puesto que la validez de la ILP radica 
en la presentación de 500.000 firmas en su totalidad. 

Desde una vertiente más académica, en [6] los autores 
proponen un sistema de recogida de firmas digitales enfocada 
a procesos de ILP. En dicho artículo, se presenta el diseño 
a alto nivel de la plataforma eFIC (Firma Ciudadana), una 
plataforma que permite la recogida de firmas. No nos consta, 
a día de hoy, que la plataforma propuesta en dicho artículo se 
haya implementado. 

Finalmente, desde el punto de vista práctico, hasta la fecha 
únicamente el proceso de ILP pro-trasvase Tajo-Segura[1] con- 
templa la recogida de firmas digitales. Esta ILP acepta firmas 
digitales que se pueden realizar a través de su portal web 
utilizando el DNI electrónico. La aplicación que se encarga de 
la gestión de las firmas digitales es una aplicación desarrollada 
por el departamento de informática de la Universidad de 
Murcia. Más allá del “Manual del firmante” que se encuentra 
disponible en la web de la Iniciativa, no se disponen de más 
detalles de la aplicación. 

En lo que respecta al punto de vista jurídico, no tenemos 
constancia, a día de hoy, de la existencia entre la doctrina 
española de trabajos dedicados específicamente a la recogida 
de firmas electrónicas para el desarrollo de una ILP, por lo 
que el tema es abordado de forma incidental en trabajos 
generalistas y sin entrar a resolver la problemática jurídica 
planteada. 

En este artículo se presenta una aplicación que permite la 
recogida y validación de firmas digitales para una ILP. La 
aplicación propuesta cumple con los requisitos establecidos 
por la ley y dicho cumplimiento se analiza tanto desde el 
punto de vista técnico como desde el punto de vista jurídico. 

La organización del artículo es la siguiente. En la Sección 
TI se analiza la ley que regula los procesos de ILP. La Sección 
III presenta las principales características de la aplicación 
desarrollada. En la Sección IV se presenta un análisis jurídico. 
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Finalmente, en el Sección V se presentan las conclusiones. 


II. BREVE DESCRIPCIÓN DE LA LEY ORGÁNICA 3/1984 


La presentación de una ILP da comienzo con la constitución 
de una comisión promotora, encargada de presentar el texto 
que será objeto de la Iniciativa. La comisión promotora 
deberá presentar el texto a la Mesa del Congreso, que llevará a 
cabo un examen de admisibilidad. Si la propuesta es admitida, 
se prosigue con la ILP. 

El proceso de recogida de firmas se inicia en el momento 
en el que la Mesa del Congreso admite la proposición y lo 
comunica a la Junta Electoral Central (JEC) y termina con 
la entrega de las firmas recogidas a la JEC, para su posterior 
comprobación y recuento definitivo. Se requieren un mínimo 
de 500.000 firmas que deben ser recogidas y validadas en un 
plazo de nueve meses. 

Una vez recogidas las firmas exigidas y entregadas a la JEC, 
ésta procederá a su comprobación y recuento definitivos, inva- 
lidando las firmas que no cumplan los requisitos establecidos. 
La JEC elevará al Congreso de los Diputados la certificación 
acreditativa del número de firmas válidas y procederá a destruir 
los pliegos que contenían las firmas. 

Por último, se inicia la tramitación parlamentaria. Recibida 
la acreditación con el número de firmas exigido, la Mesa 
ordenará la publicación de la proposición, que quedará en 
condiciones de ser incluida en el orden del día del Pleno. 


IT-A. Proceso de recogida de firmas 


El proceso de recogida de firmas se inicia cuando la 
comisión promotora presenta a la JEC los pliegos necesarios 
para la recogida de firmas, que deberán reproducir el texto 
íntegro de la proposición. La JEC, una vez aprobado el texto 
que contienen los pliegos, los devolverá sellados y numerados 
a la comisión promotora, que se encargará de la recogida de 
firmas. 

Una vez la comisión promotora ha obtenido los pliegos, se 
procede a la recogida de firmas. Las firmas deberán ir acom- 
pañadas del nombre, apellidos, número de DNI y municipio 
en cuyas listas electorales se encuentre inscrito el elector y 
deberán ser autenticadas por un Notario, un Secretario Judicial, 
el Secretario municipal o por fedatarios especiales designados 
por la comisión promotora. La autenticación deberá incluir la 
fecha, que podrá ser colectiva, pliego por pliego. 

El procedimiento de recogida de firmas debe finalizar con 
la entrega de las firmas recogidas a la JEC en el plazo de 
nueve meses desde la notificación. Las firmas deberán ir 
acompañadas de los certificados que acrediten la inscripción 
de los firmantes en el censo electoral como mayores de edad. 


II-B. Identificación de los procesos tradicionales en un en- 
torno digital 


En este apartado, identificamos los documentos y procesos 
establecidos por la ley en un entorno digital. 

El texto íntegro de la proposición es un documento 
electrónico con el mismo contenido. El equivalente digital 
de los pliegos serán unos documentos digitales análogos. A 


diferencia de los pliegos en papel, que contienen espacio para 
distintas firmas manuscritas, los pliegos en formato digital so- 
lamente contendrán la firma digital de un único ciudadano (no 
por dificultad tecnológica sino por simplificación conceptual). 
La información que contendrá un pliego digital será: 


Pliego = XP, sti, Fp,3gc,nombre, DNI, municipio y 


donde P es el documento con el texto íntegro de la propo- 
sición, Fp. go es la firma de la JEC sobre la propuesta y 
su sello de tiempo, st¡, nombre es el nombre y apellidos 
del ciudadano, DNI es el número del documento nacional 
de identidad, y municipio es el municipio en cuyas listas 
electorales se encuentre inscrito el ciudadano. 

Nótese que el equivalente digital al sellado de los pliegos 
por parte de la JEC es la firma de la propuesta por parte 
de la JEC, Fp. gc, y su inclusión dentro del pliego. Esta 
firma digital va acompañada de un sello de tiempo st, que 
permitirá establecer el inicio del periodo de recogida de firmas. 

La recogida de firmas manuscritas se convierte ahora en una 
recogida de firmas digitales. Los ciudadanos que deseen dar 
soporte a la iniciativa, deberán firmar digitalmente el Pliego, 
obteniendo Fpyje 0.0 

La contabilización de una firma digital en la ILP vendrá de- 
terminada (más allá de su correcta validación, que discutimos 
más adelante) por la validez legal de la firma digital emiti- 
da. Dicha validez dependerá de la autoridad de certificación 
que haya emitido el certificado digital que cada ciudadano 
esté utilizando para realizar la firma. Para ello, el sistema que 
realiza la validación de las firmas digitales deberá especificar 
las autoridades de certificación aceptadas para la firma de una 
propuesta. Dichas autoridades debe fijarlas la JEC. 

La correcta contabilización de la firma para la propuesta de 
ILP debe contener las siguientes validaciones: 

1. La firma debe estar realizada correctamente por el sus- 

criptor del certificado digital. 

2. El certificado digital debe estar vigente a fecha de 

realización de la firma. 

3. La firma no se ha realizado antes de la fecha de inicio 

de recogida de firmas. 

4. La firma no se ha realizado con posterioridad a la fecha 

límite de recogida de firmas. 

5. Un usuario no puede firmar más de una vez. 

6. El usuario debe ser mayor de edad. 

Dichas validaciones las puede efectuar tanto la comisión 
promotora, como la JEC. En la Sección III se describen 
los mecanismos específicos que se han implementado en la 
aplicación para realizar dichas validaciones. 

La entrega de las firmas digitales a la junta electoral central 
se realizará en soporte digital. Para ello, se remitirán todos los 
documentos, Pliego, y sus correspondientes firmas, P Pliego.c 
para que la JEC pueda realizar las comprobaciones oportunas 
para efectuar el recuento final. 


III. APLICACIÓN DE RECOGIDA DE FIRMAS 


La aplicación de recogida de firmas desarrollada utiliza 
una arquitectura estándar cliente-servidor. El servidor dispone 
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de una base de datos donde se almacenan las proposiciones 
creadas y las firmas realizadas para cada una de ellas. También 
el servidor es el encargado de realizar todas las tareas de 
validación y sellado de tiempo. El cliente, para realizar la firma 
digital de la proposición deseada, sólo necesita un navegador 
web y un par de claves certificadas por una autoridad de 
certificación reconocida por la JEC. En el caso que las claves 
no estén en el navegador web del usuario, éste puede precisar 
también dispositivos para el acceso a las claves (como un 
lector de tarjetas inteligentes en el caso del DNI electrónico). 

La aplicación no se ha desarrollado como una aplicación 
standalone sino que se ha desarrollado como un componente 
de Joomla, un gestor de contenidos de código abierto. Esto per- 
mite integrar la aplicación de recogida de firmas en cualquier 
sitio construido sobre esta plataforma. El componente se ha 
desarrollado utilizando PHP como lenguaje de programación 
y MySQL como sistema gestor de base de datos. 

La aplicación dispone de tres perfiles de usuario diferencia- 
dos: el administrador, que se ocupará del funcionamiento de la 
plataforma; el gestor, la persona que creará las proposiciones; 
y el usuario, el ciudadano que podrá firmar las mismas. 

El administrador es el encargado de gestionar la plataforma 
y, como tal, dispone de una interfaz especial donde configurar 
las diversas opciones. Las tres principales acciones de adminis- 
tración son la configuración de las autoridades de certificación 
y sellado de tiempo, la configuración de la visibilidad de las 
proposiciones y la descarga de las firmas realizadas. En primer 
lugar, para que un gestor pueda crear una nueva proposición 
que acepte una determinada autoridad de certificación, el admi- 
nistrador tiene que haber insertado la autoridad de certificación 
en la base de datos junto con su certificado. La segunda de las 
acciones de administración, la configuración de la visibilidad 
de las proposiciones, permite decidir si las propuestas son 
publicadas inmediatamente después de ser creadas o si, por 
el contrario, necesitan la aprobación del administrador antes 
de ser publicadas. La tercera de las acciones, la descarga de 
firmas, permite realizar el último trámite del procedimiento de 
recogida de firmas. Esta opción crea un fichero con el texto de 
la propuesta y las firmas efectuadas, que deberá ser entregado 
a la JEC para su validación y recuento final. 

El gestor es la persona que crea la proposición en la 
plataforma y ejerce, por tanto, el papel de comisión promotora. 
En el momento que el gestor crea la proposición, éste establece 
cuales de las autoridades de certificación que el administrador 
ha configurado desea que sean reconocidas para firmar la 
proposición. El hecho de aceptar unas autoridades de certi- 
ficación u otras permitirá crear proposiciones válidas para ser 
presentadas como ILP o recogidas de firmas más informales. 

Los usuarios de la plataforma son los ciudadanos que desean 
firmar las proposiciones. Éstos pueden listar las proposiciones 
creadas (que han sido aprobadas por el administrador) y firmar 
las que deseen. Una vez localizada la proposición a firmar, 
el usuario puede acceder al contenido completo de la misma 
así como a la opción de firma. La opción de firma se encuentra 
disponible únicamente en la página que contiene el texto 
íntegro de la proposición, asegurando que los usuarios tengan 


conocimiento de la iniciativa que suscriben. Además, el propio 
navegador exige una confirmación por parte del usuario antes 
de realizar la firma. En algunos navegadores, el mismo diálogo 
de confirmación muestra el texto íntegro a firmar, reafirmando 
el conocimiento del texto que se está firmando. Para que un 
usuario pueda firmar una proposición, es necesario que éste 
disponga de un certificado de firma emitido por alguna de las 
autoridades de certificación que fueron seleccionadas por el 
gestor en el momento de la creación. En caso que así sea, el 
usuario puede proceder a realizar la firma de la proposición. 


IFA. Validaciones que realiza la aplicación 


Más allá de las funcionalidades de gestión que realiza la 
aplicación, un punto muy importante son las validaciones que 
ésta realiza sobre las firmas digitales que obtiene, puesto que 
la eficacia de la aplicación radica en la verificabilidad de 
las firmas obtenidas. En la aplicación se han implementado 
aquellas validaciones que realizará posteriormente la JEC para 
certificar el número de firmas válidas. 

En primer lugar, se comprueba que la firma haya sido 
realizada correctamente por el suscriptor del certificado digital. 
Esta comprobación permite asegurar que la firma realizada por 
el suscriptor corresponda a una firma del pliego en cuestión. 
Esta verificación es necesaria puesto que la firma digital se 
realiza en el dispositivo del cliente y el texto que se firma 
puede haber sido modificado y puede diferir, por tanto, del 
texto original de la proposición. Para que una firma sea 
considerada como válida también es necesario comprobar que 
el certificado con el cual se ha realizado es adecuado. 

En segundo lugar, se verifica que el certificado que el 
ciudadano ha usado para firmar está vigente a fecha de 
realización de la firma. Esta comprobación requiere la veri- 
ficación del periodo de vigencia del certificado y de su estado 
de revocación. La verificación del periodo de vigencia se 
realiza comprobando los campos de validez del certificado. 
La comprobación del estado de revocación del certificado es 
llevada a cabo a través del protocolo OCSP. Esta validación 
precisa de un sello de tiempo que se puede incluir en cada 
una de las firmas digitales y que deberá ser realizado por una 
autoridad de sellado de tiempo reconocida por la JEC. Si bien 
esta opción es técnicamente válida, la obtención de un sellado 
de tiempo tiene un coste económico asociado (del orden de 
20.000 euros para 500.000 sellos), de modo que el sellado 
de tiempo de cada una de las firmas recogidas incrementa 
de forma muy notable el coste económico de la ILP. Sin 
embargo, dado que la ley permite que el establecimiento de 
la fecha puede ser colectivo, se puede aplicar a un conjunto 
determinado de firmas digitales un único sellado de tiempo, 
acreditando de este modo que dichas firmas no se han realizado 
con posterioridad a la fecha del sellado. Es importante destacar 
que, la opción del sellado de tiempo colectivo implica que la 
fecha de realización de la firma difiera de la fecha en la que 
se puede demostrar que efectivamente se ha realizado la firma 
(fecha en la que se realiza el sellado de tiempo) y por tanto 
es necesario que el certificado sea válido en esta segunda, de 
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modo que, de forma efectiva, la comprobación de la vigencia 
del certificado es realizada después del sellado de tiempo. 

En tercer lugar, es necesario comprobar que la firma no 
se haya realizado antes de la fecha de inicio del periodo de 
recogida de firmas. Nótese que la firma Pliego ya asegura 
que la firma no se ha realizado antes de la fecha de inicio 
de recogida de firmas puesto que el ciudadano incluye en su 
firma el valor Fp,.jec que equivale al sellado del pliego por 
parte de la JEC y que ya incluye la fecha en la que la JEC 
realizó la firma. 

En cuarto lugar, se debe comprobar que la firma no se ha 
realizado con posterioridad a la fecha límite de recogida de 
firmas. Para asegurar este punto se dispone del sello de tiempo 
que se realiza para la firma, ya sea éste para cada firma o para 
un conjunto de ellas. 

En quinto lugar, se debe asegurar que el usuario no pueda 
firmar más de una vez la misma proposición. El control de 
duplicados es llevado a cabo por el sistema gestor de la base 
de datos en base al número de DNI del firmante, que se extrae 
del certificado que éste ha usado para firmar. 

Por último, queda por comprobar que el usuario que ha 
realizado la firma es mayor de edad. Esta comprobación se 
puede realizar únicamente si el certificado usado para firmar 
contiene la fecha de nacimiento de su propietario, de lo 
contrario esta comprobación quedará en manos de la JEC. 


IHIFB. Especificación del formato de los datos 


Las firmas realizadas por los usuarios son almacenadas en 
una base de datos relacional. En concreto, se almacena un 
objeto signedData de PKCS+7 [7] codificado en base 64, que 
contiene tanto el certificado del usuario como el de la autoridad 
de certificación que lo ha emitido y la firma realizada. El 
objeto PKCS+7 no contiene el texto que se ha firmado, es 
decir, la firma es detached. Esto supone un ahorro de espacio 
considerable puesto que, en caso contrario, sería necesario 
almacenar el texto a firmar tantas veces como firmas se 
hubieran realizado. De este modo, el espacio estimado para 
almacenar las 500.000 firmas de una ILP es de 2GB que pue- 
den ser incrementados hasta 6GB si se añaden sellos de tiempo 
individuales para cada firma y se almacenan las respuestas de 
las comprobaciones de revocación de certificados. 

Tanto las comprobaciones de revocación de certificados 
como los sellos de tiempo realizados sobre las firmas son 
almacenados en la base de datos, los primeros codificados en 
base 64 y los segundos en el formato de timestamp response 
especificado en la RFC 3161 [8] codificado en base 64. 

Una vez se ha alcanzado el número de firmas necesarias, 
éstas deben ser presentadas ante la JEC. La exportación de 
las firmas se realiza mediante un fichero XML que contiene 
toda la información relativa a la proposición. El documento 
contiene el texto completo de la proposición, todas las firmas 
recogidas con sus respectivas comprobaciones de revocación 
y los sellos de tiempo realizados sobre las firmas. 


IV. ANÁLISIS JURÍDICO 


Como se ha expuesto, tanto Ley Orgánica 3/1984, de 26 de 
marzo, reguladora de la Iniciativa Legislativa Popular (tras la 


reforma introducida por la Ley Orgánica 4/2006, de 26 de ma- 
yo) permite declarar, de forma genérica, la admisibilidad legal 
de una recogida de firmas realizada por medios electrónicos. 
A partir de esta admisibilidad genérica, se trata de analizar el 
cumplimiento de los distintos requisitos que de forma concreta 
se establecen legalmente para el desarrollo de una ILP en 
caso de que esta se desarrolle por medios electrónicos; y en 
concreto, el cumplimento de esos requisitos por parte de la 
aplicación informática objeto de este trabajo. 


1. El procedimiento de recogida de firmas. Conforme al 
art. 7 LOILP, admitida la proposición puede iniciarse el 
procedimiento de recogida de firmas. Y la admisión genérica 
de firmas digitales nos plantea distintas cuestiones y dudas a la 
vista de la concreta regulación del procedimiento de recogida 
de firmas establecida en los siguientes preceptos: 


A. Requisitos formales previos: los pliegos para la recogida 
de firmas (art. 8). Conforme a la LOILP (art.8), y para el 
supuesto de recogida de firmas manuscritas tradicionales, la 
primera actuación de la Comisión Promotora, una vez admitida 
la proposición, es presentar ante la JEC los pliegos necesarios, 
en papel de oficio, para la recogida de las firmas. 

Para el supuesto de firmas digitales, partimos del presu- 
puesto de que la finalidad de tales exigencias de pliegos 
debidamente sellados y numerados es evitar posibles ma- 
nipulaciones, falsedades o confusiones. Y, en la aplicación 
objeto de estudio entendemos que, efectivamente, se consiguen 
similares garantías por cuanto, de entrada, el texto íntegro de 
la propuesta legislativa es firmado por la JEC que, además, 
incluirá el correspondiente sello temporal. Esta firma, junto 
con su inclusión, como veremos, en el pliego digital, es el 
equivalente funcional del sellado del art.8; y con esta firma se 
evita cualquier manipulación del contenido de la propuesta. 
Además, en la aplicación objeto de estudio, el equivalente 
digital de los pliegos son unos documentos digitales análogos, 
unos “pliegos digitales” que contendrán, entre otra informa- 
ción, el documento con el texto íntegro de la proposición, la 
firma de la JEC sobre la propuesta y su sello de tiempo (en 
cumplimiento de las exigencias del art. 8 LOILP), y también 
el nombre y apellidos del ciudadano, el número del documento 
nacional de identidad, y el municipio en cuyas listas electo- 
rales se encuentre inscrito el ciudadano (en cumplimiento de 
las exigencias del art. 8 LOILP). Y cada uno de estos pliegos 
contendrá la firma digital de un ciudadano, firma que afectará a 
la totalidad de la información contenida en el pliego digital. 
De esta forma, los pliegos que contienen el texto íntegro de 
la propuesta firmada por la JEC quedan vinculados a la firma 
de los ciudadanos, por cuanto el documento que firman los 
usuarios es, precisamente, la propuesta firmada por la JEC; de 
esta forma se evitan posibles actuaciones fraudulentas (en el 
sentido de incluir firmas suscritas con finalidades distintas o 
utilizar las firmas recogidas para otros objetivos). 

Por otra parte, la exigencia del art. 8 de que los pliegos 
reproduzcan el texto íntegro de la proposición, entendemos 
persigue la finalidad de que los firmantes tengan conocimiento 
pleno y fundada de la iniciativa que suscriben; y entendemos 
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que ello puede conseguirse igualmente, e incluso de forma 
más plena y eficaz, en el caso de ILP telemática incluyendo 
en la página de recogida de datos un enlace a la propuesta o 
incluso, configurándolo como página de paso obligatorio. 
Además, recuérdese que, en la aplicación objeto de estudio, 
esta firma digital de la Junta Electoral va acompañada de un 
sello de tiempo de especial relevancia a efectos de determinar 
la validez temporal de las firmas recogidas. En efecto, como 
es sabido, sólo las firmas recogidas dentro de plazo son firmas 
válidas, no siendo admisibles las recogidas con anterioridad al 
inicio del periodo de recogida, ni las suscritas con posteriori- 
dad a la finalización de dicho plazo. De ahí la importancia de 
la prueba del momento temporal de realización de la firma. 
En la aplicación objeto de análisis, en caso de descartar, por 
sus costes, el sellado temporal individual de cada una de las 
firmas, se proponen otros medios indirectos de prueba de la 
validez temporal de la firma recogida que pueden considerarse 
igualmente válidos, por cuanto aun cuando no prueban el 
momento exacto en que se ha realizado tal firma si consiguen 
probar su realización dentro del periodo legalmente válido de 
recogida. 

B. Momento de la firma. Los ciudadanos que deseen apoyar 
la iniciativa legislativa propuesta deberán firmar digitalmente 
el pliego digital. Y esta actuación nos plantea, jurídicamente, 
dos cuestiones. 

Los firmantes: sujetos legitimados para firmar. De acuerdo 
con lo dispuesto en la LOILP (art. 1), pueden ejercer la ILP 
los ciudadanos españoles mayores de edad que se encuentren 
inscritos en el censo electoral (y en pleno ejercicio del derecho 
de sufragio activo). 

Y, precisamente, a efectos de identificación y comprobación 
de la legitimación de los firmantes, el art. 9 LOILP, relativo 
a la autenticación de las firmas, dispone que, junto a la firma 
del elector se indicará su nombre y apellidos, número del 
documento nacional de identidad y municipio en cuyas listas 
electorales se halle inscrito. 

En el supuesto de recogida de firmas digitales, entendemos 
que la identificación y comprobación de la legitimación puede 
realizarse con igual o incluso superior seguridad y, sin ninguna 
duda, con mayor rapidez y eficacia. En concreto, en el caso 
de la aplicación objeto de estudio, si la firma digital admitida 
es la incorporada al denominado DNI electrónico, será posible 
extraer esos datos personales de la misma información incor- 
porada al chip electrónico del mismo y la aplicación puede 
realizar la comprobación de la mayoría de edad. 

La firma digital; clases de firma admisibles. Dado lo 
novedoso del sistema de firma digital que admite el art. 7.4 
LOILP, la escasa doctrina que ha abordado el tema considera 
necesario esperar a una norma de desarrollo que establezca 
los requisitos de seguridad que hagan posible y fiable el 
recurso a la firma electrónica para la recogida de firmas. Y 
doctrinalmente, se han apuntado dos posibilidades respecto 
del impulso de esta norma de desarrollo: un acuerdo de 
la Mesa del Congreso de los Diputados o una Instrucción 
o Resolución de la JEC, considerándose más correcta esta 
última, por cuanto, conforme al art. 7 LOILP, corresponde 


a la JEC el control de la regularidad del procedimiento de 
recogida de firmas [9]. 

En la práctica, de forma reciente, se ha optado por una vía 
próxima a esta segunda solución. En concreto, hemos de 
referirnos al Acuerdo de la Junta Electoral de 28 de mayo de 
2009 que supone su primer pronunciamiento respecto del uso 
de la firma digital en el desarrollo de ILP y que dispone que 
la Comisión promotora debe comunicar a la JEC “el sistema 
de firma electrónica que pretenda utilizar y facilitar a ésta, 
en el caso de que fuera necesario, el sistema utilizado para 
la verificación de las firmas electrónicas”. La finalidad de tal 
comunicación entendemos que es la validación por parte de 
la Junta de la validez legal del sistema de firma. Obsérvese, 
pues, que la Junta Electoral, tras reiterar la admisibilidad de la 
recogida de firmas digitales para los procedimientos de ILP no 
establece a continuación los requisitos que de forma general 
deban cumplir los sistemas de firma digital (ni siquiera remite 
a una resolución o instrucción de desarrollo posterior) sino que 
adopta el mecanismo de la comunicación previa y autorización 
para cada caso concreto. 

Y, por ello, este primer acuerdo va seguido de otro Acuerdo 
de 28 de enero de 2010 que nos sitúa ya ante la comunicación 
previa de un concreto sistema de firma digital por parte de 
la Comisión Promotora (la Comisión Promotora de la ILP 
Tajo-Segura) que pretende utilizar las nuevas tecnologías para 
la recogida de firmas y pretende obtener la autorización a 
tal efecto de la JEC. Y tal autorización se otorga por la 
mencionada Junta con el informe previo de la Oficina del 
Censo Electoral (que, conforme a la LOILP, interviene en la 
comprobación y recuento previos de las firmas recogidas). 
Vistos estos aspectos procesales relativos a la autorización del 
sistema de firma, nos centramos ahora en aspectos sustantivos 
relativos a la clase de firma admisible. Y, en principio, ha 
de tenerse en cuenta la regulación de la firma electrónica 
que nos sitúa en la Ley 59/2003, de 19 de diciembre, de 
firma electrónica; y, de entre las distintas clases de firma 
electrónica que contempla la Ley, nos inclinamos por la 
utilización, de la denominada firma electrónica reconocida 
que, por sus características, está equiparada legalmente a la 
firma manuscrita (en virtud del art. 3 de la Ley 59/2003). 
Mención especial merece el denominado DNI electrónico, 
regulado inicialmente en los art. 15 y 16 de la Ley 59/2003 y 
en el Real Decreto 1553/2005, de 23 de diciembre (cuyo art. 
1.5 lo equipara también a la firma manuscrita). Por ello, dada 
la seguridad que ofrece la firma incorporada, y dado el grado 
de difusión actual del DNI electrónico, resulta un instrumento 
especialmente adecuado para la recogida de firmas digitales 
para el desarrollo de una ILP. 

C. Autenticación de la firma. A fin de evitar fraudes, los art. 
9 y 10 LOILP establecen las exigencias de autenticación de las 
firmas, exigencias cuyo cumplimiento constituye, como hemos 
visto, una de las condiciones impuestas por la Junta Electoral 
para la admisibilidad de las firmas digitales. 

En concreto, dispone el art. 9.2 que, en principio, la firma debe 
ser autenticada por un Notario, por un Secretario Judicial o por 
el Secretario municipal correspondiente al municipio en cuyo 
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censo electoral se halle inscrito el firmante. 

Junto a esta autenticación realizada por los fedatarios tradicio- 
nales, el art. 10 de la LOILP abre una interesante posibilidad 
para los supuestos de ILP electrónica, en la medida que 
establecen que “las firmas podrán también ser autenticadas por 
fedatarios especiales designados por la Comisión Promotora”. 
Posibilidad que permite que actúen como fedatarios personas 
con los conocimientos técnicos suficientes y necesarios para la 
autenticación de firmas electrónicas, personas que podrían ser 
propuestas por el administrador de la aplicación informática 
de entre sus empleados, lo que permitiría un procedimiento 
de autenticación más ágil y eficaz. Téngase en cuenta que 
para adquirir esta condición de fedatarios especiales debemos 
estar ante “ciudadanos españoles que, en plena posesión de sus 
derechos civiles y políticos y careciendo de antecedentes pena- 
les, juren O prometan ante las Juntas Electorales provinciales 
dar fe de la autenticidad de las firmas de los signatarios de la 
proposición de Ley” (art. 10.2); y que, dada la transcedencia de 
su actuación, la adquisición de tal condición no es irrelevante 
pues, en caso de falsedad, los fedatarios especiales puede 
incurrir en responsabilidad penal (art. 10.3). 

En cualquier caso, cabe plantear en qué consistiría la autenti- 
cación en el supuesto de recogida de firmas digitales. En este 
caso, partimos de la utilización de certificados identificativos 
que permiten articular la presunción iuris tantum de que quien 
está firmando es efectivamente el titular del par de claves 
certificadas; por ello, la autenticación o bien sería inexistente, 
por innecesaria, o bien consistiría en la validación o verifi- 
cación de la firma electrónica, en el sentido de comprobar 
que se cumplen con los requisitos de verificación, técnicos 
y jurídicos, necesarios para considerarla una firma válida, 
requisitos ya expuestos en la parte técnica de este trabajo. Y 
obsérvese que estas mismas actuaciones son las que deberían 
efectuar nuevamente tanto la Oficina del Censo Electoral como 
la JEC a efectos de la comprobación inicial y el recuento 
definitivo de firmas. 

2. Remisión de los pliegos a la Junta Electoral. Compro- 
bación y recuento de firmas. Una vez finalizada la recogida 
de firmas y su autenticación, conforme al art. 11.1 LOILP 
los pliegos que contengan las firmas se han de enviar a la 
JEC. La JEC, a su vez, los remite a la Oficina del Censo 
Electoral para que acredite la inscripción de los firmantes 
en el Censo Electoral como mayores de edad, y lleve a 
cabo la comprobación y el recuento inicial de dichas firmas. 
La Oficina del Censo Electoral, en el plazo de quince días, 
remitirá a la Junta Electoral Central certificación de todo ello 
(art. 11). Y, conforme al art. 12.1, una vez remitidos los 
pliegos a la JEC, esta procederá a su comprobación y recuento 
definitivos. En este momento, las “firmas que no reúnan los 
requisitos exigidos en esta Ley se declararán inválidas y no 
serán computadas” (art. 12.2). 

En la aplicación objeto de estudio, la entrega de las firmas 
digitales a la junta electoral central se realizará en soporte 
digital; para ello, se remitirán todos los documentos o pliegos 
y sus correspondientes firmas, para que la JEC pueda realizar 


las comprobaciones oportunas para efectuar el recuento final. 
Recuérdese asimismo que en el Acuerdo de 28 de mayo 
de 2010 de la Junta Electoral se establece que la Comisión 
promotora, además de comunicar a la Junta Electoral Central 
el sistema de firma electrónica que pretenda utilizar, debe 
también “facilitar a ésta, en el caso de que fuera necesario, el 
sistema utilizado para la verificación de las firmas electróni- 
cas”. Comprobado el cumplimiento de los requisitos exigidos 
para la válida presentación de la proposición (en concreto, la 
consecución de las, como mínimo, 500.000 firmas válidas), 
la JEC elevará al Congreso de los Diputados certificación 
acreditativa del número de firmas válidas y procederá a destruir 
los pliegos de firmas que obren en su poder. 

Y, a partir de ese momento se iniciaría la tramitación parla- 
mentaria de la proposición, conforme al art. 13 LOILP, lo que 
no supone, en modo alguno la aprobación de la proposición, 
que queda en manos del Pleno del Congreso. 


V. CONCLUSIONES 


En este trabajo hemos presentado de forma breve una 
aplicación que permite la recogida de firmas digitales para 
la realización de una iniciativa legislativa popular. Hemos 
descrito sus principales características y hemos detallado las 
validaciones que se llevan a cabo para cumplir con los requisi- 
tos legales que marca la ley. Por otro lado, hemos realizado un 
análisis jurídico del proceso de recogida de firmas digitales que 
nos permite concluir que aun son mejorables las normativas al 
respecto, por cuanto sigue sin existir una regulación detallada 
de los requisitos que deben cumplirse para la recogida de 
firmas digitales. 
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Resumen—En este artículo presentamos un criterio de privaci- 
dad basado en teoría de la información para la generación de 
consultas falsas en el ámbito de la recuperación de información 
privada. Medimos el riesgo de privacidad como la divergencia de 
Kullback y Leibler entre la distribución de consultas del usuario 
y la de la población, que incluye la entropía de la distribución 
del usuario como caso especial. Asimismo, llevamos a cabo 
una rigurosa justificación de nuestra métrica al interpretarla 
desde distintas perspectivas de teoría de la información, desde 
la propiedad de equipartición asintótica, pasando por los funda- 
mentos sobre los que sustentan los métodos de maximización de 
la entropía, la minimización de la divergencia y la minimización 
de la ganancia de información, hasta el lema de Stein. 


I.. INTRODUCCIÓN 


Durante las últimas dos décadas, Internet se ha ido integrando 
de manera gradual en nuestra vida diaria. Una de las activi- 
dades más frecuentes que llevan a cabo los usuarios cuando 
navegan por la Web es enviar una consulta a un motor de 
búsqueda. Los motores de búsqueda permiten a los usuarios 
recuperar información sobre una gran variedad de categorías, 
tales como hobbies, deportes, negocios o salud. Sin embargo, 
la mayoría de usuarios no son conscientes de los riesgos de 
privacidad que ello entraña [1]. 

De noviembre a diciembre de 2008, el 61 % de los adultos 
en Estados Unidos buscaron información en la red sobre 
una enfermedad en particular, un tratamiento específico, y 
otros temas relacionados [2]. Dichas consultas podrían revelar 
información sensible y ser utilizada para construir perfiles 
de usuario sobre enfermedades potenciales. Esta información 
privada podría acabar más tarde en las manos de un empresario 
y frustrar las esperanzas de uno de sus empleados. 

En la literatura sobre sistemas de recuperación de infor- 
mación abundan los casos como el descrito, en los que se 
constata la importancia de la privacidad del usuario. Estos 
casos incluyen no sólo el riesgo de que los usuarios puedan 
ser caracterizados por un motor de búsquedas de Internet, 
sino también por proveedores de servicios basados en la 
localización (LBS, location-based services), o incluso la car- 
acterización de empresas por parte de proveedores de bases de 
datos de patentes o mercados de valores. En este contexto, la 
falsificación de consultas, que consiste en acompañar consultas 
auténticas con consultas falsas, emerge como una posible 
solución para garantizar la privacidad del usuario hasta un 
cierto punto, a costa de una sobrecarga de tráfico y procesado. 
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Este artículo presenta un nuevo criterio de privacidad basado 
en teoría de la información para la generación de consultas 
en el ámbito de la recuperación de información. En concreto, 
nuestro criterio mide el riesgo de privacidad como una diver- 
gencia entre la distribución de consultas del usuario y la de 
la población, y contempla la entropía de la distribución del 
usuario como un caso particular. El objeto de este artículo 
es interpretar y justificar nuestra métrica de privacidad desde 
distintas perspectivas, a través de la propiedad de equipartición 
asintótica, el test de hipótesis y el lema de Stein. 

La Sección II revisa las propuestas más relevantes en cuanto 
a recuperación de información privada y criterios de privaci- 
dad. La Sección III repasa algunos conceptos fundamentales 
relacionados con teoría de la información que ayudarán a 
entender la esencia de este trabajo. La Sección IV presenta 
una formulación de teoría de la información sobre el com- 
promiso entre privacidad y redundancia para la falsificación 
de consultas en el contexto de recuperación de información 
privada. Esta sección muestra nuestra medida de privacidad, 
y posteriormente la interpreta y justifica. Finalmente, en la 
Sección V se presentan las conclusiones. 


II. ESTADO DEL ARTE EN RECUPERACIÓN DE 
INFORMACIÓN PRIVADA 


A lo largo de este artículo, utilizaremos el término recu- 
peración de información privada (PIR, private information 
retrieval) en su sentido más amplio, queriendo decir con ello 
que no nos ceñiremos a las técnicas basadas en criptografía 
normalmente relacionadas con este acrónimo. Por consigu- 
lente, nos referiremos a un escenario más genérico en el 
que los usuarios envían consultas de propósito general a un 
proveedor de servicios de información. Un ejemplo sería un 
usuario que enviase la consulta: “¿Cuál es la película más 
taquillera en la categoría de ciencia ficción?”. A continuación, 
revisaremos las contribuciones más destacadas para PIR sobre 
la generación de consultas falsas y criterios de privacidad. 


IIT-A. Recuperación de Información Privada 


En el ámbito de la recuperación de información privada, 
existen una gran variedad de propuestas. Algunas de ellas 
se basan en terceras partes de confianza (TTPs, trusted third 
parties) que actúan como intermediario entre los usuarios y el 
proveedor de servicios de información [3]. Aunque este tipo 
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de soluciones garantizan la privacidad del usuario gracias a 
que su identidad es, de hecho, desconocida para el proveedor 
de servicios, la confianza del usuario únicamente se traslada 
de una entidad a otra. 


Como alternativa, algunas propuestas que no se basan en 
TTPs, utilizan técnicas de perturbación. En el caso concreto 
de LBS, los usuarios perturban su información de localización 
al consultar a un proveedor de servicios [4]. Esto proporciona 
a los usuarios un cierto nivel de privacidad en términos 
de localización, pero no así en cuanto al contenido de las 
consultas y la actividad del usuario. Asimismo, esta técnica 
plantea un compromiso entre privacidad y utilidad de los 
datos: cuanto mayor es la perturbación de la localización, 
mayor es la privacidad del usuario, pero menor la precisión 
de las respuestas del proveedor de servicios. Como alternativa, 
los métodos criptográficos para PIR permiten a un usuario 
recuperar, de forma privada, el contenido de una base datos 
indexado por una dirección de memoria enviada por el usuario, 
haciendo que sea inviable por parte del proveedor de la base de 
datos averiguar qué entradas fueran recuperadas [5]. Desafor- 
tunadamente, este tipo de métodos requieren la cooperación 
del proveedor en el protocolo de privacidad, se restringen hasta 
cierto punto a funciones de consulta-respuesta en forma de 
tablas de búsqueda de longitud finita con respuestas precom- 
putadas, y conllevan una significativa carga computacional. 


La generación de consultas falsas, que el centro de nues- 
tra discusión, aparece como una alternativa a los métodos 
anteriores. La idea subyacente consiste en enviar consultas 
originales junto con consultas falsas. A pesar de la sencillez de 
este método, la falsificación de consultas es capaz de garantizar 
la privacidad del usuario hasta un cierto punto, a costa de una 
sobrecarga de tráfico y procesado, aunque sin tener que tener 
confiar ni en el proveedor de información ni en el operador 
de red. 


Basándose en este principio, se han propuesto e implementa- 
do varios protocolos PIR. En [6], [7], se presenta una solución 
que pretende preservar la privacidad de un grupo de usuarios 
que navegan por Internet compartiendo un punto de acceso a 
la Web. Los autores proponen la generación de transacciones 
falsas, 1.e., accesos a páginas web para frustrar a un atacante 
en su intento por caracterizar al grupo. La privacidad se mide 
como la similitud entre el perfil real de un grupo de usuarios 
y el observado por el atacante [6]. 


Además de las implicaciones legales, existen distintas con- 
sideraciones técnicas para la preservación de la privacidad a 
través de la generación de consultas falsas [8], puesto que 
los atacantes podrían analizar no sólo el contenido de las 
consultas sino también la actividad, el ritmo de generación, 
el enrutamiento o cualquier otro parámetro del protocolo de 
transmisión, por medio de varias consultas o a través de 
diversos servicios de información. Asimismo, se espera que 
tanto los proveedores de información como los de la red se 
muestren reticentes a la generación automática de consultas 
falsas, con lo que cualquier esquema que se precie debe tener 
en cuenta la sobrecarga de tráfico. 


Hl-B. Criterios de Privacidad 


En esta sección revisaremos una serie de técnicas propuestas 
originalmente para el control de revelación estadístico (SDC, 
statistical disclosure control), pero igualmente aplicables a 
PIR, la aplicación que motiva nuestro trabajo. En privacidad de 
bases de datos, se define un conjunto de microdatos como una 
tabla de base de datos cuyos registros contienen información 
sobre encuestados individuales. Específicamente, este conjunto 
contiene atributos clave, es decir, atributos que, utilizados 
conjuntamente, se pueden relacionar con información externa 
para reidentificar a los encuestados a los que se refieren los 
registros en el conjunto de microdatos. Como ejemplo, los 
atributos clave podrían ser trabajo, dirección, edad, género, 
peso y altura. De igual modo, el conjunto de microdatos 
contiene atributos confidenciales con información sensible 
sobre el encuestado, tales como sueldo, religión o afiliación 
política. 

Un planteamiento habitual en SDC es la microagregación, 
que consiste, primero, en dividir el conjunto de datos en grupos 
de registros con tuplas de valores de atributos clave similares, y 
segundo, en reemplazar las tuplas de cada registro en cada uno 
de los grupos por una tupla representativa del grupo. Uno de 
los criterios de privacidad más populares en la anonimización 
de bases de datos, es k-anonimato [9]. Este criterio se puede 
lograr a través de la microagregación, ya que requiere que 
cada combinación de atributos clave sea compartida por al 
menos k registros en el conjunto de microdatos. Sin embargo, 
el principal inconveniente de este criterio y de sus posteriores 
mejoras [10]-[12] es su vulnerabilidad ante los ataques de 
similitud y skewness [13]. Con el objeto de superar estas 
deficiencias, [14] propone otro criterio de privacidad. Con- 
cretamente, un conjunto de datos satisface f-closeness si, para 
cada grupo de registros que comparten una combinación de 
atributos clave, la divergencia de Kullback y Leibler (KL) 
entre la distribución de atributos confidenciales dentro de un 
grupo y la distribución de estos atributos en el conjunto de 
datos global no supera un umbral £. Inspirados en esta idea, 
[15], [16] definen riesgo de privacidad como una versión 
promediada del requisito impuesto por f-closeness sobre el 
conjunto de grupos agregados. Otro criterio de privacidad 
basado en teoría de la información propone medir el grado 
de anonimato observable por un atacante como la entropía de 
la distribución de probabilidad de los posibles emisores de un 
determinado mensaje [17], [18]. 

A pesar de las propuestas citadas anteriormente, querríamos 
poner énfasis en la posible necesidad, por parte de algunas 
aplicaciones, de criterios de privacidad basados en teoría 
de la información más sofisticados que k-anonimato o sus 
respectivas mejoras. 


TI. INTRODUCCIÓN A CONCEPTOS DE TEORÍA DE LA 
INFORMACIÓN 


A lo largo de este artículo, denominaremos alfabeto al espacio 
medible en el que una variable aleatoria (v.a.) toma valores. 
Seguiremos la convención de utilizar mayúsculas para las 
v.a's, y minúsculas para los valores particulares que éstas 
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pueden tomar. Las funciones de densidad de probabilidad 
(PDFs, probability density functions) y las funciones de masa 
de probabilidad (PMEs, probability mass functions) son de- 
notadas por p, subindexadas por sus correspondientes v.a.'s 
en caso de ambigiiedad. Por ejemplo, tanto px(x) como 
p(x) indican el valor de la función px en x, lo que ayuda 
a escribir ecuaciones más concisas. De manera informal, 
nos referiremos ocasionalmente a la función p como p(x). 
Asimismo, utilizaremos la notación px¡y y p(x|y) de manera 
equivalente. 

En este artículo, adoptamos la misma notación utilizada 
en [19] para cantidades de teoría de la información. En 
concreto, el símbolo H se referirá a la entropía y D a la 
entropía relativa o divergencia KL. A continuación recordamos 
muy brevemente varios conceptos de teoría de la información 
para aquellos lectores que no estén íntimamente familiarizados 
con este campo. Por simplicidad, utilizaremos logaritmos 
neperianos. 


= La entropía H(X) de una v.a. discreta X con distribución 
de probabilidad p es una medida de su incertidumbre, y 
se define como 
2 ele 


donde E es el operador esperanza. Este operador es 
sustituido por la integral cuando p es una PDF. 


H(X) =-—Elnp(X ) ln ple 


= Dadas dos distribuciones de probabilidad p(w) y q(x) 
sobre el mismo alfabeto, la divergencia KL o entropía 
relativa D(p || q) se define, en el caso discreto, como 


=E, jp PRO = Y ra m?22, 


D(p ll 4) ¿00 aa) 


Cuando p y q son PDFs, la esperanza se transforma en 
una integral. 


Aunque la divergencia KL no satisface la propiedad de 
simetría y la desigualdad triangular, nos da una medida de 
la distancia o discrepancia entre distribuciones, en el sentido 
que D(p ||) > 0, con igualdad si y sólo si p= q. 

Este intuitivo sentido de distancia se hace más evidente al 
examinar el lema de Stein. Suponga que observamos una se- 
cuencia de k v.a.'s independientes e idénticamente distribuidas 
(1.1.d.'s), y que necesitamos evaluar si éstas han sido generadas 
según una distribución de probabilidad p¡, hipótesis .4, O 
p2, hipótesis .42. Dadas estas dos hipótesis, definimos la 
región de aceptación .%, como el conjunto de secuencias 
que, una vez observadas, nos llevan a aceptar .4,. De forma 
análoga, definimos el complemento de este conjunto, .%, 
como el conjunto de secuencias que nos decantan por 4%. 
A continuación, contemplamos las siguientes probabilidades 
de error: 


= la probabilidad de un falso negativo az, definido como 
la probabilidad de aceptar .4% cuando .% es cierta, 

= y la probabilidad de un falso positivo Pz, definido como 
la probabilidad de aceptar .4%, cuando .%23 es cierta. 


Suponga que elegimos una región de aceptación con la inten- 
ción de minimizar Bj, mientras que no permitimos que 0, 
exceda un cierto umbral e. En términos generales, el lema de 
Stein afirma que la tasa de error óptima, P;,, es aproximada- 
mente e *P(b1 lIP2), para valores de k grandes y e pequeños. 

A modo de ejemplo, considere el test de hipótesis en el 
que observamos una secuencia X1,..., Xx de k lanzamientos 
1.1.d.'s de una v.a., e intentamos averiguar si se han producido 
de acuerdo con una distribución gaussiana p = Y (4/2, 0?) 
o pa = Y (12, 0?). Teniendo en cuenta estas distribuciones, 
elegiríamos la región de decisión óptima .%, dada por el lema 
de Neyman-Pearson [19], y calcularíamos la probabilidad de 
un falso positivo como la integral de p2(11,..., 1) sobre 4. 
Resulta que, a partir del lema de Stein, esta a a es 


aproximadamente e pad , ya que D(p1 [|p2) = 5, lo que 
hace más palpable esta noción de distancia: cuanto mayor es 
la distancia real d entre las medias de las dos distribuciones, 
mayor es la divergencia KL, y menor la probabilidad de error 
al distinguir entre ambas distribuciones. 


IV. UN CRITERIO DE PRIVACIDAD DE TEORÍA DE LA 
INFORMACIÓN PARA LA FALSIFICACIÓN DE CONSULTAS 


Esta sección presenta la principal contribución de este trabajo, 
un nuevo criterio de privacidad basado en una cantidad de 
teoría de la información para la falsificación de consultas en 
PIR. En concreto, la Sección IV-A introduce nuestra medida 
de privacidad, lo que nos conduce al problema de optimización 
mostrado en la Sección IV-B en el que se presenta el com- 
promiso óptimo entre riesgo de privacidad y redundancia. 
Posteriormente, interpretamos y justificamos nuestra medida 
de privacidad desde distintos puntos de vista. En particular, 
la Sección IV-C investiga los fundamentos sobre los que 
se sustentan los métodos de maximización de la entropía, 
la minimización de la divergencia y la minimización de la 
ganancia de información. Para comprender estos argumentos, 
revisamos la propiedad de equipartición asintótica, el test de 
hipótesis y el lema de Stein. 


IV-A. Criterio de Privacidad 


Nuestro modelo matemático representa las consultas de 
usuario como v.a.'s que toman valores en un alfabeto común. 
Asumiremos que las consultas de usuario no son elaboradas 
o detalladas. En su lugar, éstas se referirán a un conjunto de 
categorías o temas, o de forma equivalente, podrán representar 
palabras clave en un conjunto indexable reducido. Por consigu- 
iente, consideraremos que el alfabeto es finito. En concreto, 
asumiremos que las consultas toman valores en el alfabeto 
£ =(1,...,n) para algún n € Z*. 

Teniendo en cuenta estas consideraciones, definiremos p 
como la distribución de consultas de la población, q como 
la distribución real de un usuario en particular, y r como 
la distribución de las consultas falsificadas de ese usuario. 
Asimismo, consideraremos un parámetro de redundancia de 
consultas O < p < 1, que será el ratio entre consultas falsifi- 
cadas y consultas totales. De acuerdo con esto, definiremos la 
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distribución de consultas aparente del usuario s como la com- 
binación convexa (1—p) q+pr, que será la distribución que en 
realidad observará el proveedor de servicios de información, 
o simplemente, un atacante de la privacidad. Un atacante 
será capaz de comprometer la privacidad de un usuario siempre 
que la distribución de consultas aparente de este usuario difiera 
de la distribución de consultas de la población. 

Inspirados por los criterios de privacidad propuestos 
en [14]-[17], definimos el riesgo de privacidad inicial como 
la divergencia KL entre la distribución del usuario y la de 
la población, es decir, Ro = D(q||p). De forma similar, 
definimos el riesgo de privacidad final TR como la divergencia 
KL entre la distribución aparente y la distribución de la 
población, es decir, 


R=D(sl|p) = D(U — p)a+prlp). 


IV-B. Compromiso Óptimo entre Privacidad de Consultas y 
Redundancia 


Esta sección muestra una formulación del compromiso entre 
privacidad y redundancia para la generación de consultas 
falsas, que surge de la medida de privacidad presentada en 
la Sección IV-A. Partiendo de la definición de nuestro criterio 
de privacidad, supondremos que la población es suficiente- 
mente grande como para despreciar el impacto de la elección 
de r en p. De esta forma, definimos la función privacidad- 
redundancia 


R(p) = mín D(1=p)a+prID), a) 


que representa el compromiso óptimo entre riesgo de privaci- 
dad de consultas y redundancia. 

El término mínimo que aparece en la definición de la función 
privacidad-redundancia está justificado por el hecho de que 
el problema de optimización planteado implica una función 
acotada inferiormente y semi-continua inferiormente sobre un 
conjunto compacto, que es el símplex de probabilidad al que 
pertenece r. 

Teniendo en cuenta esta formulación, conviene apreciar 
que es posible obtener resultados teóricos análogos para una 
definición alternativa del riesgo de privacidad, dada por la 
inversión de los argumentos de la divergencia KL. En la 
Sección IV-C2 se dan más detalles sobre esta formulación 
alternativa. 


IV-C. Interpretación y Justificación 


En esta sección interpretaremos y justificaremos la divergencia 
KL como criterio de privacidad en la definición de la función 
privacidad-redundancia. En concreto, examinaremos los argu- 
mentos en la literatura que abogan por la maximización de la 
entropía, y la minimización de la divergencia y la ganancia de 
información. 

Antes de proceder a la interpretación y justificación de nues- 
tro criterio de privacidad, querríamos comentar que, aunque 
nuestra propuesta surge de una cantidad de teoría de la 
información y resulta matemáticamente tratable, la adecuación 


de nuestra formulación está supeditada a la adaptación de los 
criterios optimizados, que a su vez depende de varios factores 
tales como la propia aplicación, el modelo de adversario y 
los mecanismos en contra de la privacidad que se hayan 
contemplado. Las interpretaciones y justificaciones que aquí se 
detallan tienen por objeto ayudar a los diseñadores y usuarios 
de sistemas a evaluar la adecuación de nuestra propuesta a una 
aplicación específica de recuperación de información. 

Asimismo, querríamos poner énfasis en que, a pesar de 
que nuestro criterio de privacidad se basa en una cantidad 
fundamental de teoría de la información, la convergencia de 
estos dos campos en absoluto es nueva. De hecho, el trabajo 
de Shannon en los años cincuenta ya introdujo el concepto de 
equivocación como la entropía condicional de un mensaje pri- 
vado dada la observación de un criptograma [20], utilizada más 
tarde en la formulación del problema wiretap channel [21], 
[22] como una medida de confidencialidad. Del mismo modo, 
podemos mencionar la interpretación basada en teoría de la 
información de la divergencia entre las distribuciones a priori y 
a posterior, denominada ganancia de información promedio en 
algunos campos de estadística [23], [24]. Asimismo, estudios 
recientes [17] reafirman la adecuación y aplicabilidad del 
concepto de entropía como medida de privacidad, tal y como 
comentamos en la Sección Il. 

IV-CI. Maximización de la Entropía: Nuestra primera 
interpretación está basada, de hecho, en la idea de que la 
entropía de Shannon se puede considerar como un caso par- 
ticular del criterio propuesto en este artículo. Para comprender 
esta conexión, suponga que la distribución de consultas de la 
población es la distribución uniforme u sobre el alfabeto 2, 
es decir, que u; = 1/n para todo ¿ € 2”. En este supuesto, el 
riesgo de privacidad se puede expresar como 


D(1—p)a+prlu)=tan—H(1— p)q+pr). 


Por tanto, minimizar la divergencia KL es equivalente a 
maximizar la entropía de la distribución de consultas aparente 
del usuario: 


R(p) =lon—= máx H((— p)q + pr). 


Esta equivalencia nos conduce a las siguientes dos implica- 
ciones. En primer lugar, el criterio de privacidad H((1—p) q + 
pr) es una medida de ganancia de privacidad, más que de 
riesgo de privacidad. En segundo lugar, se trata de una medida 
de privacidad absoluta, en contraste con nuestro criterio más 
general, en el sentido que es una métrica relativa a cualquier 
distribución de referencia. 

El hecho de considerar esta medida absoluta de ganancia 
de privacidad permite acercarnos a los fundamentos sobre 
los que se apoyan los métodos de maximización de la en- 
tropía. Algunos de estos argumentos están relacionados con 
el mayor número de permutaciones con repetición asociado 
a una distribución empírica [25]. Sin embargo, el argumento 
más apropiado para la justificación de la maximización de 
la entropía, considerada como una medida de privacidad, 
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viene dado por la propiedad de equipartición asintótica (ARP, 
asymptotic equipartition property) [19, 83]. 

Suponga una secuencia Xy,..., Xy de k consultas 1.i.d.'s, 
que toman valores en .2, y son generadas de acuerdo con 
la distribución de consultas aparente del usuario s = (1 — 
p)a + pr. Para k suficientemente grande, la AEP sostiene 
que es muy probable que la secuencia de consultas 2,,..., Tx 
pertenezca a un subconjunto .7 (%) del conjunto de todas las 
posibles secuencias, denominado conjunto típico, que satisface 
estas propiedades: la probabilidad de este conjunto es apro- 
ximadamente 1, todos los elementos son casi equiprobables, 
y el número de elementos es prácticamente e*H(s). Resulta 
que la entropía está acotada superiormente por lnn, como 
consecuencia de la no negatividad de la divergencia KL, y 
alcanza su valor máximo cuando la distribución aparente es la 
distribución uniforme. A partir de esta observación, podemos 
deducir que la distribución uniforme maximiza el conjunto 
típico 7 (4) y, cuando esto sucede, éste se convierte en el 
conjunto de todos los posibles resultados, conteniendo n* 
secuencias. Puesto que H(s) caracteriza completamente esta 
aproximación, cualquier medida de privacidad con sentido 
acabaría siendo básicamente equivalente a ésta. 


Teniendo en cuenta esta conexión entre entropía y tamaño 
del conjunto típico, ahora describiremos la siguiente amenaza 
de privacidad. Suponga que un atacante intenta adivinar una 
secuencia de k consultas de un usuario en particular a partir 
de la observación de secuencias previas. Cuanto mayor sea 
la entropía H(s) de la distribución de consultas aparente del 
usuario, mayor será el tamaño del conjunto típico .7(*) de 
secuencias posibles e igualmente probables de k consultas, 
y mayor la probabilidad de que la secuencia a adivinar sea 
significativamente diferente de las anteriores. Este escenario 
nos permite concluir que los métodos de maximización de 
la entropía contribuyen ampliamente a la protección de la 
privacidad del usuario. 


IV-C2. Minimización de la Divergencia: En la sección 
anterior examinamos los argumentos que abogan por la maxi- 
mización de la entropía. En esta sección, recurriremos al lema 
de Stein, revisado en la Sección III, para nuestra interpretación 
de la divergencia como falsos positivos y falsos negativos. En 
concreto, describiremos un escenario en el que un atacante 
utiliza test de hipótesis para comprometer la privacidad del 
usuario. 


En el resto de la sección, consideraremos nuestro criterio de 
privacidad en su sentido más amplio, es decir, la distribución 
de consultas del usuario no se comparará necesariamente, en 
términos de la divergencia KL, con la distribución uniforme. 


Nuestra interpretación contempla el escenario en el que 
un atacante conoce, o es capaz de estimar, la distribución 
de consultas aparente s de un usuario determinado. Además, 
suponemos que el atacante observa una secuencia de k con- 
sultas 1.1.d.'s, e intenta adivinar si éstas han sido generadas 
por ese usuario o no. Exactamente, el atacante considera el 
test de hipótesis binario entre dos alternativas: si las consultas 
se han producido de acuerdo con la distribución aparente 


del usuario s, hipótesis 4%, o la distribución general de la 
población p, hipótesis .4. 

Llegados a este punto, un atacante podría llevar a cabo 
dos estrategias mutuamente excluyentes. La primera estrategia 
considera que el atacante está interesado en acotar la proba- 
bilidad de un falso negativo P(.2|%), dado que su objetivo 
es que el usuario no pase desapercibido. A partir del lema de 
Stein, encontramos que la probabilidad P(P|%%) de un falso 
positivo es aproximadamente e *PlsII?) para k grande. Por 
consiguiente, la minimización de D(s || p) en la definición de 
la función privacidad-redundancia (1) implica la maximización 
del exponente en la tasa de error de falsos positivos. Dicho de 
otra forma, la distribución óptima de consultas falsas r* frustra 
a un atacante en su esfuerzo por reconocer a un usuario de 
entre la población, y por tanto, comprometer la privacidad del 
usuario. 

Más que fijar la probabilidad de un falso negativo, ahora 
el objetivo del atacante es minimizar la probabilidad de error 
global 


Pp =P) P( PIU) +P(P)P(U 12). 


Aprovechándose del hecho de que la actividad de la población 
global es mucho mayor que la de un único usuario, el 
atacante está interesado en acotar P(4|:92), y hacer lo posible 
para minimizar P(P|%). Resulta que la probabilidad de un 
falso negativo dado por el lema de Stein es aproximadamen- 
te e Píblls) lo que justifica una definición alternativa de 
la función privacidad-redundancia dada por la inversión de 
los dos argumentos de la divergencia KL. De acuerdo con 
esta observación, la estrategia de falsificación de consultas 
r* que minimiza D(p||s), conduce a la maximización de 
la probabilidad de error global del atacante y contribuye a 
proteger la privacidad del usuario. 

A modo de aclaración, nos gustaría destacar que, a pesar 
de que esta definición alternativa resulta oportuna en el último 
escenario propuesto, nosotros creemos que la formulación 
original es más apropiada, ya que incluye, como caso par- 
ticular, los métodos de maximización de la entropía descritos 
en la Sección IV-Cl. 

IV-C3. Minimización de la Ganancia de Información: 
Una vez analizados los principales argumentos en pro de 
la maximización de la entropía y la minimización de la 
divergencia, ahora estableceremos una conexión entre nuestro 
criterio de privacidad y el criterio propuesto en [16]. 

Considere pojw(qlu) la distribución de consultas del 
usuario u, donde U es una variable aleatoria que identifica a 
un usuario en particular y toma el valor u. Asimismo, (QQ) es una 
variable aleatoria que representa una consulta en particular, y 
toma el valor q. 

Sea po(q) la distribución de probabilidad sin condicionar 
que modela la distribución de consultas de la población. Natu- 
ralmente, pu (u) sería la probabilidad de usuario, posiblemente 
ponderada por su actividad. En esta notación, nuestra medida 
de riesgo de privacidad para el usuario u se puede escribir 
como D(pgju(-|u)llpo). De forma similar, podemos aplicarla 
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para redefinir el concepto de t-closeness. Una distribución 
satisface t-closeness si y sólo si D(poju(-u)llpg) < t para 
todos los valores u de U, lo que sugiere medir el riesgo de 
privacidad como un máximo sobre divergencias. Inspirados 
por t-closeness, [16] presenta un planteamiento más intere- 
sante en el sentido que nos permite conectar con la ganancia de 
información promedio. En concreto, el criterio de privacidad 
propuesto en [16] es la divergencia KL condicional 


D(pqjullpo) = Ev D(pqyu (10) pe), 


es decir, la información mutua entre Q y U, o de forma equi- 
valente, el promedio entre usuarios del criterio de privacidad 
definido en este artículo. En contraste con este criterio, nuestra 
medida de privacidad contempla un único usuario, pero podría, 
en principio, generalizarse a escenarios multiusuarios en una 
futura propuesta. 


V. CONCLUSIONES 


Existe una gran variedad de propuestas para PIR, considerado 
aquí en el sentido más amplio del término. Dentro de estas 
soluciones, la generación de consultas falsas surge como una 
estrategia simple en términos de requisitos de infraestructura, 
ya que los usuarios no necesitan una entidad externa en la que 
confiar. Sin embargo, esta solución plantea un compromiso 
entre la privacidad y el coste de la sobrecarga de tráfico y 
procesado. 

Nuestra principal contribución es un criterio de privacidad 
basado en teoría de la información para la falsificación de 
consultas en PIR, que emerge de la formulación del compro- 
miso entre privacidad y redundancia. Inspirados por el trabajo 
en [16], medimos el riesgo de privacidad como la divergencia 
KL entre la distribución de consultas aparente del usuario, 
que contiene consultas falsas, y la de la población. Nuestra 
formulación contempla, como caso especial, la maximización 
de la entropía de la distribución del usuario. 

En este artículo justificamos nuestro criterio de privacidad 
al interpretarlo desde distintas perspectivas, y al conectarlo 
con los argumentos en la literatura que abogan por la max- 
imización de la entropía, la minimización de la divergencia 
y la minimización de la ganancia de información. Nuestras 
interpretaciones están basadas en la AEP, el test de hipótesis 
y el lema de Stein, y el criterio de ganancia de información 
promedio propuesto en [16]. 

Aunque nuestra propuesta surge de una medida de teoría 
de la información y resulta matemáticamente tratable, la ade- 
cuación de nuestra formulación está supeditada a la adaptación 
de los criterios optimizados, que a su vez depende de varios 
factores tales como la propia aplicación, la estadística de 
consultas de los usuarios, la sobrecarga de red y de procesado 
provocados por la consultas falsas, el modelo de adversario 
y los mecanismos en contra de la privacidad que se hayan 
contemplado. 
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Resumen—La conversión de los registros de búsqueda en 
anónimos es un proceso importante y necesario previo a la 
publicación de dichos datos. Esto asegura la privacidad de 
los usuarios, un problema que ya se ha dado en los registros 
publicados por importantes compañías. El artículo presenta la 
conversión de los registros de un buscador Web en anónimos 
utilizando microagregación. Nuestra propuesta garantiza el k- 
anonimato a nivel de usuario preservando la utilidad de los datos. 


I.. INTRODUCCIÓN 


Los registros (o logs) generados por un buscador Web 
(WSE) son una fuente interesante de información para inves- 
tigadores o compañías de marketing, pero al mismo tiempo, 
su publicación supone una amenaza contra la privacidad de 
los usuarios de los WSEs. Existe un caso conocido en el cual 
la publicación de este tipo de información, con un nivel de 
anonimato pobre, ha permitido la reidentificación de algunos 
usuarios. AOL publicó unos registros de su buscador, supues- 
tamente anónimos, con el propósito de ayudar la comunidad 
científica y acabó con un daño irreparable hacia la privacidad 
de sus usuarios y daños contra la propia empresa con diversas 
quejas y denuncias [8], [17]. 

La dificultad de la convertir en anónimos los registros de 
búsqueda es conseguir un buen balance entre privacidad y 
utilidad. Existen algunas propuestas para conseguir anonimato 
este tipo de datos [3], pero generalmente se limitan a borrar 
información específica de los registros. Es más, técnicas de 
control de revelación estadística (statistical disclosure control, 
SDC) no han sido aplicadas a este tipo de datos hasta muy 
recientemente [18], [10]. 

En este artículo proponemos el uso de la microagregación 
para proporcionar anonimato en registros de búsqueda. Nuestra 
propuesta consigue un alto grado de privacidad, proporcionan- 
do k-anonimato a nivel de usuario, y preservando, hasta cierto 
punto, la utilidad de los datos. 

El artículo está organizado como sigue. La sección II 
introduce el problema y nuestras motivaciones. En la sec- 
ción II presentamos nuestra propuesta de microagregación. 
La sección IV contiene una evaluación de la propuesta en 
términos de privacidad y utilidad de datos, y finalmente la 
sección V presenta las conclusiones. 


TI. MOTIVACIONES 


Un registro de búsqueda de un WSE está compuesto por 
líneas con la estructura: 


(id, 4, t, r, u) 


donde id es el identificador de usuario, q son los términos de 
búsqueda, t es el timestamp, u es la URL seleccionada por 
el usuario después de la búsqueda, y r es la posición de la 
URL seleccionada en el resultado de la búsqueda. Este formato 
corresponde a los registros publicados por AOL en el 2006. La 
Figura 1 muestra algunas de estas líneas reales de los datos de 
AOL. La información proporcionada en estos registros es la 
misma que la de los registros publicados por AllTheWeb [11], 
y muy parecida a otros registros publicados por Excite [13] o 
AltaVista [12]. Normalmente se considera como un formato 
de registro de búsqueda genérico. 

Nuestro trabajo se centra en los registros de AOL. Hemos 
de tener en cuenta que estos datos han sido convertidos a 
anónimos con técnicas bastante pobres. La URL seleccionada 
(u) es cortada a nivel de nombre de dominio y la información 
sensible de los términos de búsqueda ha sido eliminada 
(números de la seguridad social, ...) [25]. El identificador 
de usuario (id) es un identificador único, su anonimato se 
consigue mediante una función hash o técnicas similares. Se 
ha demostrado que a pesar de esta protección los usuarios 
pueden ser identificados [2]. Es más, el uso de técnicas de hash 
aplicadas a los términos de búsqueda puede ser vulnerable al 
análisis de frecuencia [15]. 

Se han desarrollado otras técnicas para conseguir anonimato 
en registros de búsqueda como la eliminación de búsquedas 
poco frecuentes [1], o propuestas más sofisticadas para 
eliminar búsquedas concretas que permitan preservar un nivel 
de privacidad aceptable [20], o escoger las búsquedas que se 
pueden publicar [14]. 

El trabajo presentado en este artículo parte de una propuesta 
inicial [18], que has sido mejorada tanto en términos de 
eficiencia como en los resultados obtenidos. 


IFA. k-anonimato a nivel de usuario 


Un principio muy utilizado en el control de revelación 
de datos estadísticos (SDC) es el k-anonimato [21], [22], 
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24963762 
24964082 
24967641 
24967641 
24969374 
24969374 


myspace codes 2006-05-31 23:00:52 2 
bank of america 2006-05-31 19:41:07 
donut pillow 2006-05-31 14:08:53 

dicontinued dishes 
orioles tickets 2006-05-31 12:31:57 
baltimore marinas 


2006-05-31 14:29:38 


2006-05-31 12:43:40 


http: //www.myspace-codes.com 


http://www.bankofamerica.com 


http://www.greatseats.com 


Figura 1: Ejemplo de registro de un buscador Web. 


que especifica que cada consulta de los datos anónimos 
debe retornar como mínimo k registros iguales. Conseguir k- 
anonimato a nivel de usuario en los registros de búsqueda es 
el principal objetivo de nuestra propuesta, ya que previene la 
reidentificación de los usuarios que era posible en los registros 
inicialmente publicados por AOL [2]. 

Para conseguir k-anonimato a nivel de usuario aplicamos 
microagregación a los registros, lo que permite no tener que 
borrar explícitamente ninguno. Para poder microagregar los 
registros de búsqueda a nivel de usuario, consideramos como 
un solo registro todos los registros de un mismo usuario. Es 
decir, hay un registro por usuario, y cada registro contiene 
todos los registros de dicho usuario, que son tratados como 
un todo en el proceso de protección. 

Un importante inconveniente de nuestra propuesta es que se 
pierde algo de información en los datos protegidos. Como en 
casos similares siempre existe un balance entre privacidad y 
utilidad. En nuestro caso, mostramos que, aún consiguiendo 
un nivel de privacidad muy alto, los datos siguen preservando 
suficiente utilidad para ser usados en procesos de data-mining 
o análisis estadístico. 


TI. MICROAGREGACIÓN DE REGISTROS DE BÚSQUEDA 


Para poder aplicar microagregación a los registros de 
búsqueda debemos definir el proceso de microagregación. En 
las secciones siguientes introducimos la microagregación y 
como la utilizamos para proteger registros de búsqueda. 


TIFA. —Microagregación 


La microagregación es una técnica de control de revelación 
estadística (SDC), que proporciona privacidad mediante la 
agrupación de los datos en pequeños clústers y sustituyendo 
luego los datos originales por los representantes (centroides) 
del clúster correspondiente. 

La privacidad se consigue porqué cada clúster tiene un 
número mínimo predefinido de elementos: hay al menos k 
registros con el mismo valor. Todos los registros del clúster 
cambian su valor por el del centroide del clúster. La constante 
k es un parámetro que controla el nivel de privacidad del 
método. A medida que aumentamos k conseguimos más 
privacidad en los datos protegidos. 

La microagregación fue originalmente propuesta para atri- 
butos numéricos [4], aunque más tarde fue ampliada a otros 
dominios. Por ejemplo, a datos categóricos en [23] (ver 
también [7]), o a entornos con restricciones en [24]. 

Desde el punto de vista operacional, la microagregación se 
define en términos de partición y agregación: 


= Partición. Los registros se dividen en clústers, de manera 

que cada clúster tenga al menos k registros. 

= Agregación. Para cada clúster, se calcula un represen- 

tante (centroide), y se sustituyen los registros originales 
por dicho representante. 

Desde un punto de vista formal, la microagregación se 
puede definir como un problema de optimización con algu- 
nas restricciones. Damos una formalización a continuación 
utilizando u;,, para denotar la partición de registros en el 
conjunto de datos original X. Esto es, u;¿= 1 si el registro 
está asignado al clúster ¿. Sea v, el representante del clúster 2; 
la formulación general de la microagregación con g clústers y 
dado el parámetro k es: 


Minimizar SSE =D j_1 Dj=1 ig (dx, w1))? 


Sujeto a )7_, u¡¿ = 1 para todo ¿=1,...,n 
2k > Dj=1 U4j > kparatodo¿=1,...,g 
Uuij € (0,1) 


Para datos numéricos, generalmente d(x,v) corresponde a 
la distancia Euclídea. En el caso general, cuando se consideran 
los atributos V = (V,..., Vs), w y v son vectores y d pasa 
a ser d“(x,0) = y ey (ti — 01)”. Además, suele ser común 
en datos numéricos definir v; como la media aritmética de los 
registros del clúster. Es decir, v, = Fica uta) Dj Urge 
Dado que la solución a este problema cuando se considera 
más de una variable a la vez (microagregación multivariable) 
es NP-Hard [19] se han desarrollado métodos heurísticos. 

MDAV [5] (Maximum Distance to Average Vector) es uno 
de estos algoritmos heurísticos. Se encuentra descrito con 
detalle en el Algoritmo 1, donde se aplica a un conjunto de 
datos X con n registros y A atributos. La implementación de 
MDAYV para datos categóricos se da en [7]. 

Nótese que cuando todas las variables se consideran al mis- 
mo tiempo, la microagregación es una manera de implementar 
k-anonimato [21], [22]. 


IHIFB. Distancia y agregación de registros de búsqueda 


Para microagregar registros de búsqueda a nivel de usuario, 
necesitamos definir una distancia adecuada para particionar 
los datos y un operador de agregación para el cálculo del 
centroide. 

Denotamos cada usuario ¿d; como: 

aid;) = (id;, p") 
donde p* = (1, P2,P3,---) es el vector de búsquedas hechas 
por el usuario ¿d,. Es decir, (p; corresponde a la búsqueda ; del 
usuario ¿d;, y esta compuesta por (p; = [t;, 77, U¿, P7), donde 


4 E El 
$; = (Lo, M1, ua, -..) es la cadena de búsqueda (términos 
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Algorithm 1: Algoritmo MDAV 


Data: X: conjunto de datos original, k: entero 
Result: X”: conjunto de datos protegido 


1 begin 

2 while (|[X| > 3x k) do 

3 Calcular el registro medio x de todos los 
registros en X; 

4 Seleccionar el registro x, más distante al registro 
medio 2; 

5 Formar un clúster entorno a x2,. El clúster 


contiene x, junto a los k— 1 registros más 
cercanos a ty; 


6 Borrar estos registros del conjunto X; 

7 Seleccionar el registro u, más distante del 
registro 2,.; 

8 Formar un un clúster entorno a x,. El clúster 


contiene x, junto a los k — 1 registros más 
cercanos a 25; 


9 Borrar estos registros del conjunto X; 

10 if ([X] >= 2x k) then 

11 Calcular el registro medio x de todos los 
registros en X; 

12 Seleccionar el registro x, más distante al registro 
medio 2; 

13 Formar un clúster entorno a x,. El clúster 


contiene x, junto a los k— 1 registros más 
cercanos a ty; 


14 Borrar estos registros del conjunto X; 
15 Formar un clúster con los registros restantes; 
16 end 


de búsqueda introducidos por el usuario). También utilizamos 
lp*|] para denotar el número de búsquedas del usuario ¿d;, y 
[9;| para el número de términos de búsqueda (palabras) en la 
búsqueda ¡j del usuario ¿d;. 

Un paso previo a la microagregación es la normalización 
de los datos numéricos: timestamp, posición, número de 
búsquedas por usuario, y número de términos por búsqueda. 
Dicha normalización se hace en el intervalo [0, 1]. El número 
de búsquedas normalizado del usuario ¿d; se denota como |*!, 
y el número de términos normalizado en la búsqueda O; como 


16. 

HIF-B1. Distancia: La distancia se calcula como la agrega- 
ción de varias funciones de distancia para cada par de usuarios. 
Definimos la siguientes funciones de distancia: 


" dencialt,y) = y (u— y)?: distancia euclídea que se 
utiliza para la posición r. 

= di(t;,t,): distancia entre dos timestamps t,, t2, como la 
distancia euclídea de su representación en UNIX epoch. 

= d.(u;,u;): distancia entre dos nombres de dominio 
(URL clicada). Dados dos nombres de dominios: X = 
Causa 1 O lo Yo, y asumiendo que m > n, 


la distancia es: 
du(X, Y) = y W;¡Q;í 
¿=0 


donde w, = 277*/(27 — 1) y a; =0 si x, = y; (case- 
insensitive string equality) o 1 en caso contrario. Es decir, 
d,, es una media con pesos de «,, donde consideramos 
más importante la parte derecha del nombre de dominio. 

" die (x,y): la distancia de Levenshtein (o edit distance) 
normalizada entre dos cadenas de caracteres x, y. 

= dsld;, 05): distancia entre dos cadenas de búsqueda 
(términos introducidos por el usuario) como: 

1 (105) +10] 


delpi, pj) = a * + du l(ds, d) 


donde dy, es la distancia de Hausdorff definida en el 
espacio métrico (ju, de»), donde ¡u es el conjunto de todas 
las palabras ¡u;. Cada búsqueda se representa como un 
conjunto de palabras o términos f; = [11, 15,...) y se 
utiliza la distancia Levenshtein para compararlos. De esta 
manera tenemos que: 


dulo1, da) = máx(I (91,92), Inda, P1)) 
donde 


Inló1,b2) = o diev(Hi, M5) 

En este caso dy tiene en cuenta la similitud de los térmi- 
nos entre cadenas de búsqueda, pero también considera 
el tamaño de la cadena de búsqueda, algo que la distancia 
de Hausdorff no considera por sí sola. 

" dol, pj): distancia entre dos búsquedas de la forma 
pi = (t;,r;,u;, d;), como la media de las distancias 
correspondientes: 


1 
dolp1, pa) = q (tr, t2), deuciialr1,72), du (us, uz), 
deló1, P2)) 


Dadas las funciones de distancia anteriores, la distancia final 
entre dos usuarios se calcula como: 


a(a(ida), aida) =3 (¡T+TA + dro", 9?) 


donde d+, es la distancia de Hausdorff en el espacio métrico 
(p, d¿), y donde p es el conjunto de todas las búsquedas y”. 

III-B2. Agregación de usuarios: Para determinar el cen- 
troide de un un clúster de registros de usuarios, calculamos 
su agregación (C) como la agregación de cada parte de las 
búsquedas del usuario: 


Cla(id,),...,q(ids)) = (id',Cole”,...,p*)) 


donde, id” es un identificador temporal para el centroide que 
será sustituido por el identificador original del usuario en los 
datos protegidos. 
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De la misma manera, la agregación de búsquedas C, se 
define como: 


Calo yop) =Ce (Co, há 0) 

== p* 

= (61, ---, Olor) 
El centroide (p* está compuesto de las cadenas de búsqueda 
del clúster (p? para ¿ = 1...k. Por cada vector de búsqueda 
original p*, eso es, todas las búsquedas del usuario ¿, tomamos 
un sub-vector (p** de búsquedas tal que: 

y — Je le" 
[p**] = A 

ys j=1 [1] 
(op... ] 
frecuencia de cadenas de búsqueda del original y”. De manera 


más formal, dada una función de frecuencia f sobre cadenas 
de búsqueda, se tiene que cumplir que, 


Hop") = Fe) 


*,1 


Estas búsquedas, Y = lin) preservan la 


donde, 


Her) = Ho lp = 3" pep 
Pq [pat] 
donde ; = (pj si las cadenas de búsqueda de ambas peticiones 
son iguales, es decir, si y solo si f; = f;. 

Las otras partes de las peticiones se agregan utilizando la 
media aritmética para el rango, y el timestamp, y generalizan- 
do la URL a la parte más común (sub-dominio). 


IFC. Ejemplo de agregación de usuarios 


A continuación mostramos un ejemplo muy sencillo y 
simplificado de la agregación de búsquedas de usuario an- 
teriormente propuesta. Consideramos tres usuarios uj], Ua, y 
uz. Para simplificar el ejemplo únicamente consideramos las 
cadenas de búsqueda de cada petición. 


u | all blues 
u1 | blues for alice : 

u | the blues and beyond | a u* =C(ui, uz, uz) 
uz | all blues =, pl all blues 
uz | alice a on green dolphin street 
ug | on green dolphin street u the blues and beyond 


uz | miles davis blues 


Cuadro I: Ejemplo de agregación de búsquedas de usuario. 


El Cuadro 1 muestra las búsquedas de los tres usuarios, 
así como el resultado de su agregación. 


IV. EVALUACIÓN 


Para evaluar nuestra propuesta hemos probado la micro- 
agregación con datos reales de los registros de AOL hechos 
públicos en 2006, que corresponden a las consultas realizadas 
por 650,000 usuarios durante tres meses. Para nuestro estudio, 
hemos seleccionado aleatoriamente 1,000 usuarios de los 
registros, que corresponden a 55,666 líneas de consultas de 
los registros. 

En las siguientes secciones, medimos la privacidad conse- 
guida con nuestro método y la utilidad de los datos protegidos. 


IV-A. Porcentaje de Perfil Expuesto 


Para cada usuario ¿d disponemos de su conjunto original 
de consultas y y sus correspondientes protegidas mediante 
nuestro sistema de microagregación (po. Con la finalidad de 
verificar que nuestro método protege las consultas de los 
usuarios ofreciendo k-anonimato hemos usado el Porcentaje 
de Perfil Expuesto (PPE) [9] que se define de la forma 
siguiente: 


Ip, e”) 
H(p) 


donde H(p) es la entropía del conjunto original de con- 
sultas, y I(p,p') es la información mutua entre p y '. 
Nótese que p y py” pueden ser observadas como dos variables 
discretas. 

El PPE mide el porcentaje de información del usuario que 
se ve expuesto cuando y” es revelada. Así, la información del 
usuario se calcula como la entropía de y, y la información 
mutua proporciona una medida de la información que y' 
proporciona sobre y, es decir, cuando (Y es conocido, en 
cuanto se reduce la incertidumbre sobre «y. 


PPE = - 100 
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Porcentage de Perfil Expuesto 


4h del grupo 
PPE mf k-anonimidad ---=-=- 


Figura 2: PPE medio para k € (2,...,10). 


Hemos microagregado los 1,000 usuarios de los registros de 
AOL para k € 42,...,50). A continuación hemos calculado 
el PPE para cada usuario y valor de k. 

La Figura 2 muestra para k = (2,...,10) el nivel de 
privacidad teórico, es decir, el nivel de k-anonimato, y la media 
del PPE obtenido. Así, podemos ver que nuestro método 
ofrece k-anonimato, ya que el PPE teórico y el obtenido son 
muy parecidos. 


IV-B. Pérdida de información 


La primera medida de utilidad para datos categóricos fue 
presentada en [6]. Los autores proponen una medida basada en 
la entropía de los datos para evaluar la pérdida de información 
en SDC. En la misma línea, en [16] se propone medir la 
pérdida de información como: 


lentropia_original — entropia_nueva]| 


ILR= 100 


entropia_original 
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Hemos escogido el /LR (Information Loss Ratio) para 
evaluar la utilidad de nuestra propuesta con los mismos fiche- 
ros obtenidos previamente cuando calculamos el PPE,. Así, 
tenemos 1,000 usuarios y sus consultas originales, y para cada 
k € [2,...,50) las correspondientes consultas protegidas de 
cada usuario. La Figura 3 muestra la utilidad de los datos 
desglosada según el parámetro k de la microagregación. Se 
puede observar como al crecer k (eso es, el número de usuarios 
por clúster crece), la pérdida de información del usuario 
también crece. 


Porcentaje de perdida de informacion 
a 
g 
r 
n 


5 10 15 20 25 30 85 40 45 50 
4H del grupo 
Perdida de informacion ma 


Figura 3: ILR medio para k € [2,...,50). 


IV-C. Sobre la relación entre PPE y ILR 


El PPE y el IER nos ayudan a establecer un equilibrio 
entre privacidad y utilidad de los datos (pérdida de informa- 
ción). 

Usando una k grande tenemos una gran pérdida de infor- 
mación (1 LR), tal y como se puede observar en la Figura 3. 
Para k = 35 perdemos el 50% de la información del usuario, 
y para k = 3 sólo perdemos un 10%. Por tanto, el mínimo 
ILR proporciona los datos más útiles, y consecuentemente 
debemos seleccionar los valores más pequeños de k. 

Sin embargo, como se ve en la Figura 2, una k grande 
ofrece mayor privacidad para los usuarios, esto es, su perfil 
está menos expuesto. Por ejemplo, cuando k = 2, el 50% 
del perfil del usuario está expuesto, y para k = 10 sólo el 
10% se expone. Desde el punto de vista de la privacidad, una 
k grande sería recomendable para proteger la privacidad de 
los usuarios. Sin embargo, consideramos que el perfil de un 
usuario está suficientemente protegido si su PPE es menor 
al 40%, es decir, k = 3 (ver [9]). 

Así, podemos concluir que el valor óptimo de k para la 
microagregación es k = 3, porqué obtenemos un nivel de pri- 
vacidad razonable (PPE) y una baja pérdida de información 
(LR). 


V. CONCLUSIONES 


En este artículo hemos introducido una técnica que garantiza 
el k-anonimato a nivel de usuario en registros de búsqueda 
mediante la microagregación. Para hacer público los registros, 
éstos tienen que ser protegidos para prevenir la revelación de 
información sensible así como la reidentificación de usuarios. 


Como siempre sucede en el campo de la SDC, existe un 
balance entre la privacidad y la utilidad. Mostramos como 
nuestra propuesta proporciona k-anonimato, manteniendo cier- 
ta información de los registros originales. Por consiguiente, 
nuestra propuesta se puede ver como un método eficiente 
y relativamente sencillo de proteger registros de búsqueda, 
si lo comparamos con otras propuestas existentes, y que 
permite garantizar, siempre que sea necesario, un alto nivel 
de anonimidad y privacidad. 
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Resumen—En la recuperación de información con privacidad 
(RIP), el usuario quiere obtener información de una base de 
datos sin que ésta conozca lo que está buscando. La mayoría 
de los protocolos actuales sobre RIP son poco apropiados para 
motores de búsqueda o grandes bases de datos, debido a su 
complejidad y a la suposición de que la base de datos coopera 
activamente en el protocolo de RIP. Con una base de datos no- 
cooperativa, puede ser útil una comunidad por pares (peer-to- 
peer, P2P), donde los pares sometan consultas por cuenta de un 
usuario. De esta forma se obtiene la recuperación de información 
con privacidad de usuario (RIPU), una propiedad mediante la 
cual la base de datos conoce la información que se ha recuperado 
pero sin saber por quién. 

En este artículo se presenta un análisis mediante teoría de 
juegos de RIPU por pares (RIPUP): i) se especifica una métrica 
para medir la privacidad de un par frente a la base de datos 
y frente al resto de los pares; ii) se calcula la utilidad de las 
diferentes estrategias que puede seguir un par con el objetivo 
de maximizar su privacidad; iii) mediante la maximización 
de esta privacidad, para cada nueva consulta se obtiene un 
comportamiento racional a seguir para cada par, lo que permite 
la automatización del proceso de decisión de los pares. 

Una conclusión relevante es que un par debe ayudar al resto 
de pares con el objetivo de maximizar su propia utilidad de 
privacidad; también es destacable que, cuanto más heterogénea 
sea la tasa de generación de consultas por parte de los pares, 
más racionalmente serviciales serán estos. 


Palabras clave— Recuperación de información con privacidad 
(Private information retrieval), Recuperación de información con 
privacidad de usuario (User-private information retrieval), Preser- 
vación de la privacidad en minería de datos (Privacy-preserving 
data mining), Teoría de juegos (Game theory). 


I.. INTRODUCCIÓN 


El objetivo de la recuperación de información con pri- 
vacidad (RIP) es permitir a un usuario obtener información 
de una base de datos sin que ésta sepa en qué información 
está interesado. En la literatura sobre RIP (véanse los artículos 
seminales [6], [7] y los más recientes [11], [1]) la base de 
datos se modela como un vector, y se supone que un usuario 
desea recuperar el ¿-ésimo elemento del vector manteniendo 
el índice ¿2 oculto ante la base de datos. Si bien esta visión 
de los protocolos de RIP permite desarrollos teóricos, existen 
algunas suposiciones que dificultan su implementación en la 
práctica: 
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= En general, la base de datos no puede modelarse como 
un vector en el que el usuario conoce la dirección física 2 
del campo en el que está interesado (e.g. piénsese en un 
usuario haciendo una consulta a un motor de búsqueda); 

= Si la base de datos contiene n elementos, los protocolos 
teóricos de RIP tienen una complejidad O(n) [6], [7]: 
el protocolo debe “tocar” todos los registros para evitar 
dar al servidor cualquier pista sobre el valor de ¿, lo que 
no es viable para grandes bases de datos y/o motores de 
búsqueda [3]; 

= Se supone que el servidor de la base de datos coopera en 
el protocolo de RIP; es el usuario quien está interesado en 
proteger su propia privacidad, mientras que la motivación 
para el servidor de la base de datos es dudosa; en 
realidad, es probable que la RIP sea poco atractiva para 
la mayoría de las compañías que ofrecen bases de datos 
consultables, ya que limita su capacidad de generación 
de perfiles. 

Por las razones anteriores, en la práctica se deben flexibilizar 
las suposiciones de RIP. A continuación repasamos algunas 
propuestas. 

En primer lugar, se debe tener en cuenta que los sistemas de 
onion-routing como Tor [12] no están pensados para ofrecer 
recuperación de información con privacidad. Estos sistemas 
protegen el transporte de datos, pero no ofrecen ninguna 
protección extremo a extremo (a nivel de aplicación). Como 
un motor de búsqueda o un servidor de base de datos puede 
vincular las consultas consecutivas sometidas por el mismo 
usuario (e.g mediante el uso de galletas), se puede crear un 
perfil y reidentificar al usuario. 

En [5] se propone un sistema denominado Goopir, en el que 
el usuario enmascara su consulta añadiendo k — 1 consultas 
falsas y luego envía la consulta enmascarada resultante a 
un motor de búsqueda o a una base de datos grande, que 
no tiene por qué cooperar (de hecho, ni siquiera tiene que 
saber que el usuario está tratando de proteger su privacidad). 
Estrictamente hablando, Goopir no da RIP según lo definido 
anteriormente, sino que proporciona h(k)-RIP, ya que encubre 
la consulta dentro de un conjunto de k consultas de entropía 
al menos h(k). Este sistema funciona bien, pero supone que 
las frecuencias de las palabras clave y expresiones que pueden 
aparecer en una consulta son conocidas y están disponibles: 
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para una mayor privacidad, las frecuencias de la consulta real 
y las falsas deben ser similares, por lo que la incertidumbre 
h(k) del motor de búsqueda sobre la consulta real es máxima. 

TrackMeNot [13] es otro sistema práctico basado en un 
principio diferente: en lugar de someter una única consulta 
enmascarada por cada consulta real como hace Goopir, se ins- 
tala una extensión en el navegador del computador del usuario 
para ocultar las consultas reales de éste en un conjunto de 
consultas “fantasma” automáticas sometidas a los motores de 
búsqueda más populares en diferentes intervalos de tiempo. Si 
bien esto es factible a pequeña escala, si el uso de TrackMeNot 
se generalizara, la sobrecarga introducida por las consultas 
fantasma degradaría de forma significativa el rendimiento de 
los motores de búsqueda y las redes de comunicaciones. Por 
otra parte, el intervalo de sumisión de las consultas fantasma 
automáticas puede ser distinguible respecto al intervalo de 
sumisión de las consultas reales, lo que daría pistas a un 
intruso para identificar las consultas reales. 

Con el mismo espíritu práctico, el sistema descrito en [8] 
encubre a un usuario en una comunidad anónima de pares 
(peer-to-peer, P2P). El usuario somete consultas en nombre 
de los pares anónimos y viceversa. Las parejas de usuarios de 
la comunidad P2P comparten claves de cifrado simétricas que 
utilizan para establecer un canal confidencial. De este modo, 
la base de datos sigue conociendo qué elemento se quiere 
recuperar (lo que se desvía de la RIP estricta), pero no puede 
obtener los historiales de las consultas reales de los usuarios, 
que quedan difusos entre los usuarios pares; llamamos a 
esta flexibilización de RIP recuperación de información con 
privacidad de usuario (RIPU). Este enfoque tiene sin duda 
algunas ventajas: a diferencia de [5], no requiere ningún 
conocimiento de las frecuencias de todas las posibles palabras 
clave y expresiones a consultar; a diferencia de [13] evita la 
sobrecarga de la sumisión de consultas fantasma. Además de 
preservar la privacidad del perfil de consultas del usuario frente 
a la base de datos y a intrusos externos, el sistema en [8] 
ofrece privacidad frente a los usuarios pares, porque los pares 
son anónimos entre sí. 

En [4] se propone otro enfoque RIPUP. Aquí se logra el 
anonimato con la ayuda de un nodo central que pone en 
contacto a un grupo de n usuarios que quieren someter una 
consulta. Los usuarios ejecutan un protocolo de recuperación 
de consultas anónimas por el que cada usuario puede obtener 
una consulta de uno de los n— 1 usuarios restantes, sin saber 
a qué usuario pertenece la consulta. Cada usuario envía la 
consulta recibida a la base de datos, y retransmite al resto de 
usuarios la respuesta obtenida de la base de datos. De este 
modo, el usuario que originalmente publicó la consulta puede 
obtener la respuesta correspondiente. 

En [14] se presenta una alternativa RIPUP basada en una 
red social. Básicamente, un usuario A emite una consulta 
hacia uno de sus contactos en la red social, llamado B; B 
o bien somete la consulta directamente a la base de datos 
o bien la envía a uno de sus contactos, por ejemplo C, y 
así sucesivamente hasta que un nodo someta la consulta. La 
respuesta de la consulta de A es devuelta a través del camino 


inverso. El objetivo es mantener las consultas de cada usuario 
A frente al resto de la forma más uniforme posible, obteniendo 
así la máxima privacidad frente a la base de datos. Una 
característica atractiva de este sistema es que se utiliza una 
red social existente como una comunidad de pares, lo que 
hace que la implementación sea más fácil. 


LA. Contribución y plan del artículo 


Los sistemas RIPUP como los propuestos en [8] y [14] 
se pueden formalizar como un juego. En este artículo se 
especifica una métrica para la privacidad de los pares frente 
a la base de datos. Se calculan las utilidades de privacidad 
de las diferentes estrategias que puede seguir un par con el 
objetivo de maximizar su privacidad. Maximizar la utilidad 
de privacidad para cada nueva consulta produce un compor- 
tamiento racional para cada par, lo que permite automatizar el 
proceso de decisión de estos. En particular, se determinan las 
condiciones bajo las que se alcanza un equilibrio de Nash [9], 
[10] entre pares. Dado este equilibrio, la mejor opción para 
que un par maximice su privacidad es que otro par someta 
su consulta, y la mejor opción para que el resto de pares 
maximice su privacidad es someter la consulta de otro par 
a la base de datos. 

El juego RIPUP se formaliza en la Sección II. Los resultados 
de simulación se presentan en la Sección III. La Sección IV 
resume las conclusiones y las futuras líneas de investigación. 


II. FORMALIZACIÓN DEL JUEGO RIPUP 


Consideremos ahora un sistema con N jugadores Q?, ---, 
QN, y un servidor de base de datos BD. Para cada 2, 
supongamos que (2* origina una consulta. Luego (2? tiene dos 
estrategias posibles a seguir: 

Sit: 

Sij: 


Q* somete su consulta directamente a la BD; 
Q* envía su consulta a Q?, para alguna j 4 iy 
solicita a (27 que someta la consulta en nombre de 
Q”. 

Cuando (Q? recibe la consulta de Q*, éste tiene dos posibles 
estrategias a seguir: 


Tji: Q7 somete la consulta de Qí a la BD y devuelve el 
resultado a Q?; 
Tjj: Q? ignora la consulta de Q* y no hace nada. 


Sea X*(t) = (4, ==, %;,() el conjunto de consul- 
tas originadas por Q” hasta el instante t. Sea Y”(t) = 
ly, -.- ml ¿+ el conjunto de consultas sometidas por Q'a 
la BD hasta el instante +. Sea Y (1) € X"(t) el conjunto de 
consultas originadas por Q* y enviadas a Q? hasta el instante 
t. Definimos el estado A*(t) de Q* en el tiempo t como las 
siguientes N + 1 tuplas 


(0*(a,t), CT rats) 
(s (y, t), SES o t)) 
sl (23, t), co”) fu eo t)) 


para j € [1,---, NY, con j Xi, donde o' (x%,,t) es el número 
de veces que la consulta 1, € X*(t) ha sido originada por 


142 


Q* hasta el instante t, s'(y;,,t) es el número de veces que la 
consulta y!, € Y*(t) ha sido sometida por Q!, y fU(x1,,t) es 
el número de veces que la consulta 2? orginada por Q* ha 
sido enviada a Q? hasta el instante de tiempo +. 
Claramente, 
Z 


JLo NN) 
Definimos d*(t) =|X*(t) UY*(t)| y 


FU xi, t) < o(25,,t) 


Para l =1,---,d*(t), definimos 


(4,t) =4 


o(x1.,t) if zi =x%, € X*(t) para cualquier k 
Dif gx (0) 


it) = s(y;.,t) if zi = yí, € Y*(t) para cualquier k 
EDI 04 2eYio 
PA D= Fx; t) if 2 = xl, € X'(t) para cualquier k 
bo 0. if zi g X“(t) 
La privacidad de (* frente a la BD en el instante t se define 
como 


di(t) 


> (ov(21,t) —si(2j,t))? 


l=1 


aX (1), Y (0) = 


La privacidad de Q* frente a Q7 en el instante t se define 
como 


di(t) 


aX, Y 4 (0) =D (o (4,0) - FU(4,t)) 


[=1 
Las utilidades de las estrategias de Q* y QY son 


Usalt+ 1) =(d(X*(t + D), Y (t+1)))22 


HI 


ref1,- NA 


(AX U(t+1),Y "(e)" 


Usis(t +1) = (A(X*(t +1), Y (£))) 28D 
(U(X (ES 1), Y F (+4 1)" 
NO: 


donde a; BD y Q;, son los pesos en el intervalo [0,1] que 
indican la importancia de la privacidad de Q* frente a la BD 
y Q”, respectivamente. Con Tji, tenemos X7(t+1) = X1(t), 
y YT" (t4-1) = Y 7 (£) para todos los pares r 4 j; por lo tanto: 


Urji(t+1) = (d(XHO, YY (14 1)))0.82 
(xi (e), Y (e). 
TEL NA 


Finalmente, puesto que (7 no realiza ninguna acción en Tjj, 
tenemos que 


Urj¡(t+1) = Uryy(t) = (d(X1 (0), Y(t)))%.22 


(AX (8), Y7(1)))%" 
rely) 


Dependiendo del estado de Q* en el instante t para la 
consulta 7, originada en el instante t+1, Sii o Sij para alguna 
j puede ser la estrategia que proporcione mayor utilidad a Q”; 
lo mismo vale para las estrategias T'77 y T'j1 para cualquier par 
(2/. Se debe tener en cuenta que, si Uy ¡(t+1) < Up y¿(t+1) 
para todo (7, la mejor estrategia para ()* es Si. Dado que (Q* 
no conoce las utilidades del resto de los pares, Qí debe utilizar 
el procedimiento de ensayo-error descrito en el Algoritmo 1 
para encontrar el mejor par. 


Algorithm 1 BÚSQUEDA DEL MEJOR PAR PARA (2? 


ND=(0Q*,---,QN Todos los pares son candidatos) 
sometido = 0 
while sometido = 0 do 
Calcular (2?* = arg máxoenp Usis(t +1) 
Sea Q?* el candidato al mejor par 
if j. = 1 then ] 
Someter xi [Q* somete su propia consulta) 
(a, t41):=s (21,0) +1 
sometido = 1 
else 
Enviar 2, a Q%3 
PP at, t+1) > fat, 1) +1 
if Q?* rechaza someter x7, then 
Excluir Q* de ND ([Q% rechaza la sumisión si 
Ur;,i(t +1) < Urj, 5, (t+1)) 
else 
sometido = 1 
end if 
end if 
end while 


Obsérvese que cada intento fallido en el Algoritmo 1 
implica una cierta pérdida de privacidad, ya que la consulta 
originada se revela a cada par candidato. Ello es debido a la 
actualización de f% (x%,,t +1), que influye en el cálculo del 
siguiente candidato Q?-. 

Proposición 1: Si el mejor par es Q* 4 Q* y Us (t + 
1) < Ugi;, (t + 1), entonces (Sij,(t + 1), Tj,i(t + 1)) es 
un equilibrio de Nash para el juego entre Q* y Q% con 
estados(A*(t), A%* (t)). 

Demostración: Si Q% 4 Q*, se tiene que Us;¡(t + 1) < 
Usij.(t+1) y Ur. i(t+1) > Urs, 5, (t+1), y la proposición 
se cumple. 


TII.. RESULTADOS EXPERIMENTALES 


En esta sección, presentamos los resultados experimentales. 
En las simulaciones, el Algoritmo 1 encuentra el mejor par 
casi siempre en el primer intento, por lo que podemos decir 
que es computacionalmente barato. 

El tiempo transcurrido entre dos consultas consecutivas de 
un par ()* se ha generado muestreando una variable aleatoria 
con distribución exponencial con parámetro A;. Por lo tanto, 
la tasa de generación de consultas de Q* es de A; consultas 
por unidad de tiempo, y el tiempo de espera entre consultas 
sucesivas es de 1/A,. 
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HTA. Métricas de colaboración 


Las métricas consideradas para analizar la (falta de) colab- 
oración entre pares son: 

= Consultas Sometida Directamente (CSD). Dado un par 
Q?, CSD*(t) es la fracción de las consultas generadas 
por Q* hasta el instante de tiempo t que han sido 
sometidas de forma directa a la BD por Q*. 

= Consultas Rechazadas (CR). Dado un par Q*, CR*(t) es 
la fracción de las consultas recibidas por Q* del resto de 
pares hasta el instante de tiempo t, que Q* ha rechazado 
a someter. 


HI-B. 


Se ha simulado un juego de NV pares con N = 5 durante 550 
unidades de tiempo. Suponemos que todos los pares se asignan 
la misma importancia de privacidad unos a otros y a la BD, 
y consideramos varias tasas de generación de consultas. Los 
valores de las consultas se han elegido al azar uniformemente 
entre un conjunto de 1000 consultas disponibles. La Figura 1 
muestra la evolución de las métricas CSD y CR cuando los 
cinco pares tienen la misma tasa de generación de consultas 
A = 1. Se puede observar que CSD se estabiliza entre el 50 % 
y el 70%, mientras que CR se estabiliza entre el 0% y el 
30 %. 


Influencia de la tasa de generación de consultas 


0.8 
y 0.6 
8 

0.4 

0.2 Peer1(A=11 

0 ——Peer2(2=1) 

o 100 200 300 400 500 

de Peer3(1=1) 

—Peer4(4=1) 

—Peer5(A=1) 


Figura 1: Evolución de CSD (arriba) y CR (abajo) de cinco pares 
con la misma tasa de generación de consultas (A = 1) y las mismas 
importancias de privacidad asignadas a 1 


La Figura 2 muestra la evolución de CSD y CR cuando los 
cinco pares tienen tasas de generación de consultas distintas: 
A = Le Az = 0,8, Az = 0,6, Aa = 0,4 y As = 0,2. Un 
par con una tasa de generación de consultas comparativamente 
mayor, es decir, con una A; mayor, tiende a tener un C'S Dt) 
comparativamente menor. Esto ocurre debido a que el par 
perdería una cantidad considerable de privacidad frente a la 
BD si éste se sometiera directamente todas sus (frecuentes) 


consultas. Para evitar esta pérdida, una mayor proporción de 
sus consultas debe ser sometida por otros pares. El compor- 
tamiento de CR es muy interesante y diferente del que se 
muestra en la Figura 1: en la Figura 2 la fracción CR de 
consultas rechazadas es mucho más baja para todos los pares. 
La explicación es que, como en la simulación anterior los 
pares generaban más consultas, tenían una mayor necesidad 
de someter consultas de otros pares con el fin de difuminar 
su propio perfil de consultas frente a la BD; en este caso en 
que los pares generan menos consultas, les favorece someter 
consultas de otros pares, ya que les ayudan a ocultar sus pocas 
consultas. 


——Peert(A=1) 
—Peer2(4=0.8) 
0 100 200 300 400 500 
See Peer3(2=0.6) 
1 —Peer4(1=0.4) 
0.8 
—Peer5(A4=0.2) 
0.6 
o 
E 
0.4 
0.2 
á AX 
0 100 200 300 400 500 
time 


Figura 2: Evolución de CSD (arriba) y CR (abajo) de cinco pares con 
tasas de generación de consultas diferentes y las mismas importancias 
de privacidad asignadas a 1 


HEC. Resultados utilizando consultas reales 


Para estudiar el sistema en un entorno real, se ha utilizado 
el volcado de una base de datos de AOL [2], con veinte 
millones de consultas procedentes del estudio de las consultas 
de 650000 usuarios durante un período de 3 meses. Para 
realizar esta prueba hemos elegido al azar cinco usuarios de 
entre los que tenían un mínimo de 600 consultas, con sus 
respectivas consultas emitidas por primera vez el 1 de Marzo 
de 2006. Estos usuarios emitieron sus consultas posteriores con 
intervalos muy diferentes entre una consulta y la siguiente, 
hasta el 31 de Mayo de 2006. Hemos tomado estos cinco 
usuarios, con los valores y los tiempos de sus consultas como 
si se correspondieran a cinco usuarios en nuestro sistema. 

La Figura 3 muestra la evolución de CSD y CR de estos 
cinco usuarios AOL. El gráfico se detiene tan pronto como 
uno de los usuarios ha alcanzado su consulta número 600, 
lo que sucedió por primera vez para el Usuario 4. Por lo 
tanto, las abscisas son proporcionales al número de consultas 
generadas por el Usuario 4 en lugar del tiempo. La Figura 3 
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se asemeja a la Figura 2 hasta cierto punto. La evolución de 
CSD es diferente para cada usuario: los usuarios con una tasa 
de generación de consultas más alta tienen un menor CSD. Por 
otra parte, CR es cero para todos los usuarios durante todo el 
período de tiempo: todo el mundo está siempre dispuesto a 
ayudar a otros usuarios en la sumisión de sus consultas a la 
BD. 


— AOL User 1 
o == AOL User 2 
o 100 200 300 400 500 600 
time == AOL User 3 
1 
== AOL User 4 
0.8 
—» AOL User 5 
0.6 
o 
1-3 
0.4 
0.2 
10] 
o 100 200 300 400 500 600 
time 


Figura 3: Evolución de CSD (arriba) y CR (abajo) de cinco usuarios- 
pares correspondientes a usuarios reales de la base de datos de AOL 


IV. CONCLUSIONES Y TRABAJO FUTURO 


En este artículo se ha especificado una métrica de privacidad 
basada en distancia para pares frente a una base de datos 
y frente a otros pares en un sistema RIPUP. A partir de 
esta métrica, se ha calculado la utilidad de privacidad de 
cada par. Cuando un par genera una nueva consulta, éste y 
el resto de pares toman una serie de decisiones racionales 
para maximizar su privacidad. Curiosamente, estas decisiones 
racionales conducen a menudo a los pares a ayudarse en la 
sumisión de consultas a la base de datos. De este modo, ser 
egoístamente racional en términos de privacidad lleva a ayudar 
a otros pares. En particular, se describen las condiciones en 
las que existe un equilibrio de Nash entre pares; en este 
equilibrio, la mejor opción para que un par maximice su 
privacidad es que otro par someta su consulta, y la mejor 
opción para que el resto de pares maximice su privacidad es 
someter la consulta de otro par a la base de datos. Un resultado 
empírico muy interesante es que, cuando la tasa de generación 
de consultas de los pares es heterogénea, estos están más 
dispuestos a ayudarse unos a otros en la sumisión de sus 
consultas: la frecuencia de consultas hace que sea conveniente 
enviar consultas de otros pares para esconder las propias, y 
esto también sucede cuando la frecuencia de consultas es baja. 
Por alguna razón, cuanto más se desvíe la tasa generación de 


consultas de la homogeneidad, mayor será la puesta en peligro 
de la privacidad de los pares y más se necesitaran entre ellos. 

El modelo propuesto para un comportamiento racional au- 
tomatizado en los sistemas RIPUP se puede ampliar de varias 
maneras: 


= Generalizarlo a RIPUP multi-salto, en el que un par 
pueda decidir someter la consulta de otro a la base de 
datos o enviarla a un tercero, y así sucesivamente. 

= Estudiar otras métricas de privacidad que no sean las 
basadas en distancias consideradas en este artículo, como 
por ejemplo información mutua. 

= Además de privacidad, incluir otras propiedades fun- 
cionales en las utilidades de los pares (e.g. el tiempo 
de respuesta de la consulta, número de saltos, etc.) 
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Técnicas de Anonimato para Securizar Redes 
Móviles Ad Hoc 
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Resumen—Las redes móviles ad hoc son redes formadas por la 
interconexión de terminales inalámbricos que de manera autóno- 
ma, sin ninguna administración central, establecen enlaces de 
comunicación entre ellos. La infraestructura de red la componen 
los propios terminales de usuarios que actúan de gestores y 
encaminadores de paquetes. Así, un usuario cualquiera puede 
conectarse con un terminal remoto a través de una conexión 
multisalto entre diferentes usuarios. En este tipo de redes tan 
abiertas, uno de los retos prioritarios es proteger el anonimato 
de los sujetos y sus localizaciones. En este artículo hacemos un 
repaso de las técnicas existentes a través de los protocolos que se 
han propuesto en la literatura, y exponemos los problemas que 
aun quedan abiertos. 


I. INTRODUCCIÓN 


La proliferación de dispositivos móviles en el mercado ha 
hecho surgir nuevos medios de comunicación basados en la 
creación de redes formadas por terminales de usuarios que 
se agrupan entre sí de forma esporádica y permiten construir 
una base de comunicación. Este tipo de redes reciben el 
nombre de redes móviles ad hoc (MANET) y están tomando 
especial importancia por ser unas redes que no precisan de 
infraestructura dedicada, son rápidas de desplegar, pueden 
proporcionar acceso a la información en entornos aislados y/o 
conflictivos, y su coste es reducido. 

La transmisión de datos en las redes ad hoc se realiza a 
través de los propios terminales de los usuarios, que actúan 
como encaminadores de los paquetes. Así, el rango de co- 
municación de un usuario se extiende más allá del alcance 
de sus radiaciones electromagnéticas, pudiendo crear enlaces 
de comunicaciones con nodos remotos. Empero, el hecho de 
transmitir los datos a través de terminales finales entraña una 
clara amenaza a la privacidad de los usuarios. 

Proporcionar servicios de comunicación anónima es una 
propiedad muy deseable en redes MANET. Sin embargo la 
arquitectura particular de las MANET conlleva una serie de 
características funcionales que son únicas y específicas de 
este tipo de redes, y que impiden la adopción directa de los 
esquemas de anonimato diseñados por redes cableadas. En 
concreto, cabe destacar las siguientes características: 

= La autogestión de la red se realiza a través de un medio 

abierto y susceptible a ataques externos, tanto activos co- 
mo pasivos. Los enlaces de comunicaciones inalámbricos 
permiten que los mensajes sean escuchados fácilmente 
por usuarios que no son sus legítimos receptores. 
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= La capacidad de la red y la responsabilidad de que ésta 
funcione está distribuida entre todos sus miembros. Los 
dispositivos que forman la red son terminales genéri- 
cos, con una baja protección física. La probabilidad 
que algunos de estos terminales sean comprometidos 
no es irrelevante. Ello implica tener buenos sistemas de 
detección de intrusiones y gestión de la confianza que 
permitan proteger a la red de ataques internos. 
= La topología de red es dinámica y caótica. En general, 
los terminales de la red son móviles y su estado en 
la red es transitorio e irregular. Uno de los principales 
desafíos en este tipo de entornos es el descubrimiento y 
mantenimiento de rutas de manera eficiente y anónima. 

= Los recursos de la red son limitados. Los terminales 
tienen una capacidad de proceso, memoria y batería 
reducidos. El ancho de banda también es limitado, y 
al utilizar redes inalámbricas los canales de transmisión 
sufren interferencias y devaneos. 

En este artículo definiremos las propiedades que son nece- 
sarias para proporcionar comunicaciones anónimas en redes 
ad hoc, y revisaremos el estado del arte de las técnicas 
de anonimato propuestas así como las funcionalidades que 
implementan los diferentes protocolos para MANETSs. El resto 
del artículo está organizado de la siguiente forma. En la 
sección II introducimos y clasificamos las propiedades de 
anonimato. A continuación revisamos las soluciones propues- 
tas de anonimato de usuarios (sección III), desvinculación del 
origen de los mensajes (sección IV), y indetectabilidad de la 
actividad (sección V). Finalmente, la sección VI presenta los 
principales problemas abiertos del anonimato en MANETSs. 


TI. ANONIMATO 


En primer lugar definimos las propiedades relacionadas con 

una comunicación anónima: 

1, Anonimato de los sujetos: propiedad de no ser identi- 
ficable entre un conjunto de sujetos. 

2. Desvinculación de mensajes: propiedad de ocultar la 
relación que hay entre una comunicación y los sujetos 
que la llevan a cabo. 

3. Indetectabilidad: incapacidad de distinguir si un ele- 
mento existe o no. Si consideramos mensajes, la inde- 
tectabilidad supondría que éstos no son suficientemente 
discernibles de, por ejemplo, ruido blanco. 
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Las propiedades de anonimato de una red pueden ser 
violadas por diferentes ataques, tanto activos como pasivos. 
En los ataques activos los usuarios maliciosos participan en el 
protocolo de red al que pretenden quebrantar, ya sea a través de 
ataques externos (como usuarios ajenos al sistema) o ataques 
internos (como miembros lícitos de la red). Por otro lado, 
los ataques pasivos no perturban el normal funcionamiento de 
los protocolos de red, los atacantes escuchan de forma no- 
autorizada los paquetes que se transmiten por la red y a través 
de un análisis de tráfico extrapolan información como las rutas 
de transmisión, el contenido de los mensajes, o la identidad, 
posición o movimiento de los nodos. 
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Figura 1. Taxonomía de las técnicas de anonimato para MANETs 
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En la figura 1 mostramos una taxonomía de las técnicas 
de anonimato para MANETSs: los rectángulos simbolizan las 
propiedades de anonimato, y las elipses el tipo de soluciones 
que se han propuesto en la literatura. En los siguientes 
apartados analizaremos con más detalle las propiedades de 
anonimato y las soluciones propuestas. La tabla I hace un 
resumen de las principales soluciones adoptadas por los difer- 


entes protocolos de anonimato en MANET. 
Anonimato Desvincul. 
sujetos mensajes Indetectabilidad 

Protocolo Sinon. FIramp. Loc. | Casc. RLibre MFict. 
R-AO?2P [20] S - S S - - 
MASK [23] Ss - - - Ss Destino 
ANODR [14] Ss S - Ss - - 
ASR [24] S S - S - S 
ANONDSR [18] - S - S - S 
D-ANODR [21] S - - S - - 
ARM [17] S Ss - S - S 
ARMR [11] S S - - S S 
ODAR [19] S - - S - - 
SDAR [3] - Ss - Ss - 

ALARM [8] S - Ss S - - 
PRISM [9] - - S Ss - - 
ANAP [6] Ss S - S - Ss 
RIOMO [15] S - - S - Ss 
SDDR [12] - S - S - - 

Cuadro 1 


CARACTERÍSTICAS DE LOS PROTOCOLOS DE ANONIMATO PARA MANET 


TI. ANONIMATO DE LOS SUJETOS 


En este apartado se introducen las tecnologías que permiten 
proporcionar anonimato a los sujetos. Cada una de ellas 
acomete unos usos específicos de la red. 


= Seudónimos: Usados como identificadores anónimos de 
los nodos de un vecindario. Facilitan las comunicaciones 
salto-a-salto, y que sobre éstas se construyan rutas mul- 
tisalto. 

= Funciones unidireccionales con trampa (Trapdoor 
functions): Permiten la búsqueda de nodos anónimos 
remotos. Se usan en la fase de descubrimiento de rutas 
de las MANET. 

= Rutas basadas en la localización: Permite crear rutas 
anónimas entre nodos situados en puntos concretos de la 
red. 


HFA. Seudónimos 


Una forma de esconder la identidad de los sujetos que 
actúan en una comunicación es a través de seudónimos. Éstos 
fueron introducidos en 1985 por Chaum [4] como una etiqueta 
privada que permite, de forma discrecional, distinguir a los 
participantes de una transacción. A partir de la información 
pública de la red, los nodos son incapaces de generar y/o 
vincular seudónimos para el resto de miembros de la red. 

Las dificultades que atañe poner en funcionamiento un 
sistema de seudónimos son: 


= Temporalidad: los seudónimos se tienen que renovar 
periódicamente porque su uso revela cierta información 
que se podría utilizar para identificar o localizar un 
sujeto. 

= Generación y gestión de los seudónimos: el vínculo 
entre un seudónimo y la identidad real del sujeto o 
enlace al que está asociado es privada. Sin embargo, se 
deben proporcionar mecanismos para hacer llegar esta 
información a los usuarios autorizados de forma que la 
comunicación entre entidades sea viable. 

= Autenticación: la autenticidad de los participantes en una 
transacción tendría que poder ser garantizada aunque se 
usasen seudónimos. 


Los sistemas de seudónimos más comunes son los que 
utilizan una tercera entidad de confianza (TTP) responsable 
de generar, renovar, revocar y autenticar, los seudónimos [23], 
[6], [15], [7], [13]. MASK [23] sólo requiere de una TTP para 
distribuir las claves iniciales del sistema. Sus seudónimos son 
generados en base a técnicas criptográficas por pares bilin- 
eares [2], y se distribuyen fuera de línea, antes de empezar la 
sesión ad hoc. Los seudónimos iniciales sirven para establecer 
la autenticación mutua entre dos nodos, momento a partir del 
cual generan una lista de seudónimos y claves de enlace. La 
debilidad de este esquema es que se consumen considerables 
recursos para almacenar la información de los seudónimos 
(cada nodo debe disponer de un buen grupo de seudónimos 
ya que cada uno es solo válido para la comunicación con un 
vecino). 
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El esquema RIOMO [15] propone un sistema similar a 
MASK pero más eficiente, ya que los nodos pueden au- 
togenerar sus seudónimos. Inicialmente una TTP distribuye 
un seudónimo raíz a todos los nodos con una clave secreta 
asociada. A partir de estos datos cada nodo puede generar 
seudónimos válidos en la red. Como MASK, RIOMO no pro- 
tege la identidad del destino en los procesos de descubrimiento 
de rutas. Por otro lado, el sistema es poco robusto a ataques de 
tipo Sybil, en los que un nodo adopta varias identidades con el 
objetivo de participar en múltiples comunicaciones paralelas 
por la red y obtener más información de la topología de la 
misma. Ni tan solo la TTP puede tracear la relación entre los 
seudónimos usados en la red y los identidad real de los nodos. 

Para solventar este aspecto y facilitar la autogeneración de 
seudónimos únicos, el esquema SPS [7] adopta un esquema 
jerárquico que permite que los nodos generen y revoquen sus 
propios seudónimos, pero impide que cada nodo tenga más un 
seudónimo válido durante un intervalo de tiempo. El usuario 
posee unas claves y certificados generados por una CA externa 
que son almacenados en un dispositivo tamper-proof. A partir 
de estas claves, que constituyen el nivel superior del esquema 
jerárquico, el usuario puede generarse unos seudónimos de 
segundo nivel cada vez que se necesario. 

Huang propone un esquema criptográfico basado en 
seudónimos (Password-based encryption, PBE) [13], que es 
una versión anónima de la criptografía basada en identidades 
(Identity-based encryption, IBE). De forma análoga a IBE, los 
seudónimos del PBE son usados como las claves públicas de 
los nodos. Los nodos autogeneran los seudónimos y las cor- 
respondientes claves privadas de forma totalmente autónoma, 
basándose en un conjunto de parámetros públicos del sistema. 
Para proporcionar servicios de autorización al sistema, Huang 
indica que los seudónimos pueden ser certificados de forma 
ciega por una TTP. 

Otros esquemas de generación de seudónimos no consideran 
el aspecto de la autorización de usuarios, y por lo tanto, el 
sistema es mucho más simple. Este es por ejemplo el modelo 
usado en ANODR [14]. En lugar de trabajar con seudónimos 
de identidad, ANODR utiliza seudónimos de ruta que se 
asocian a los enlaces salto a salto de una red ad hoc. Los 
seudónimos se establecen en la fase de respuesta de una acción 
de descubrimiento de rutas. Cada nodo genera un número 
aleatorio que será usado para identificar el enlace entre él, 
y el nodo previo de la ruta (posterior en la fase de respuesta). 
Los seudónimos de un enlace se pueden renovar periódica- 
mente. Por ejemplo, si emisor y receptor están sincronizados, 
pueden usar una función unidireccional para derivar un nuevo 
seudónimo cada cierto tiempo. 


HIFB. Funciones unidireccionales con trampa 


La funciones unidireccionales con trampa (trapdoor func- 
tions) son funciones unidireccionales f : X — Y tales 
que es fácil obtener f(x) para cualquier x € X, y que 
permiten el cálculo eficiente de la inversa (encontrar x € X 
tal que f(x) = y) si y solo si se posee cierta información 


adicional, la trampa. En caso contrario, el cálculo del inverso 
es computacionalmente intratable. 

Las funciones unidireccionales con trampa se utilizan para 
la identificación anónima de los receptores de una comuni- 
cación. El emisor envía la información de identificación de 
la comunicación escondida en una función trampa, de forma 
que sólo el receptor legítimo de la transmisión, que posee la 
información trampa, sea capaz de recuperarla. 

La manera más simple de implementar una función unidi- 
reccional para proporcionar anonimato de recepción es a través 
de criptografía de clave pública, como hacen por ejemplo 
los protocolos SDAR [3], ARMR [11] y AnonDSR [18]. La 
identidad del receptor se envía cifrada con la clave pública 
del propio receptor de manera que sólo él pueda abrir con 
éxito el paquete. Sin embargo, esta solución es muy costosa 
ya que el descubrimiento de rutas en redes ad hoc se hace 
a través de mecanismos broadcast de inundación, y si todos 
los nodos que reciben un paquete tienen que hacer una 
operación criptográfica para descubrir si son los receptores 
de un paquete, la carga total del sistema es insostenible. 

De forma similar a estos últimos, los protocolos ANODR 
[14] y ASR [24] utilizan criptografía simétrica para esconder 
la identidad del destino de una comunicación. En este caso se 
asume que origen y destino comparten una clave TESLA [16]. 
El origen cifra la identidad del destino y un número aleatorio 
con la clave simétrica que comparten. El nodo que pueda abrir 
este sobre y comprobar que su identificador está en él, es el 
legítimo receptor. Finalmente, en el mensaje de respuesta al 
origen, el destino envía el número aleatorio del sobre como 
prueba de recepción de éste. 

El protocolo ANAP [6] propone la utilización de funciones 
trampa más ligeras, basadas en funciones de hash. El origen 
identifica el destino de la comunicación a través del valor hash 
de su seudónimo. Sin embargo, los autores no indican cómo 
puede el origen obtener el seudónimo del destino. 


MEC. Rutas basada en la localización 


Los autores de ALARM [8] y PRISM [9] utilizan un sistema 
basado en la localización para establecer rutas con destinos 
anónimos. Los esquemas son válidos para comunicaciones que 
se establecen en función de las coordenadas geográficas de los 
nodos. Es decir, los emisores escogen el receptor no por su 
identidad, sino por su posición. Este tipo de comunicaciones 
pueden ser útiles en situaciones de desastre, en redes de 
vehículos VANET, etc. 

Tanto ALARM como PRISM utilizan una TTP externa y 
fuera de línea para emitir certificados y crear firmas de grupo 
que ofrezcan autenticidad a los elementos del protocolo sin 
revelar la identidad de los nodos. 

El encaminamiento en R-AO2P [20] también está basado 
en la localización de los nodos como método para esconder 
las identidades reales de los usuarios. El descubrimiento de 
rutas a un determinado destino se hace revelando la posición 
de un punto de referencia situado en la línea extendida entre el 
emisor y el receptor. La distancia entre el punto de referencia 


149 


y el destino es un valor aleatorio a partir del cual es difícil 
que un adversario pueda estimar la posición real del destino. 


IV. DESVINCULACIÓN DE MENSAJES 


En esta sección analizaremos las técnicas utilizadas para 
evitar que un adversario pueda inferir los sujetos que participan 
en una comunicación. 


= Mezclador (Mix router): Encaminador que esconde la 
correspondencia entre mensajes entrantes y salientes a 
partir de la modificación de su apariencia y del flujo de 
la trasmisión. 

= Red de mezcladores (Mix network): Es un conjunto de 
mezcladores interconectados. 

= Multicast anónimo (Anonymous multicast): Todo men- 
saje enviado a través de una MANET puede ser recibido 
por cualquier nodo que se encuentre en su radio de 
acción. Por tanto, es básico establecer un mecanismo 
de este tipo para montar un sistema anónimo sobre 
MANETSs. 


IV-A. Mezclador 


Un mezclador es un encaminador que recibe un conjunto 
de mensajes de entrada y los devuelve transformados de tal 
manera que no pueda relacionarse la entrada con la salida. 
Dichas transformaciones se producen tanto a nivel de forma (a 
base de aplicar técnicas de encriptación y relleno de mensajes) 
como de secuencia (a base de mezclar el orden y aplicar 
distintos retrasos en la entrega de los mensajes). 

El diseño original propuesto por Chaum [5] consiste en 
un mezclador de proceso por lotes que almacena mensajes 
en la memoria del mezclador hasta que se cumple una cierta 
condición de descarga, momento en el que se envía el lote de 
mensajes desordenados. La condición de descarga puede ser 
una condición temporal, espacial o una combinación de ambas. 
La descarga temporal se establece cada cierto período de 
tiempo (que puede ser fijo o variable) mientras que la espacial 
se establece cuando se llega a sobrepasar un determinado 
umbral de capacidad. 

El diseño original del mezclador por lotes fue extendido 
más adelante de forma que en el momento de la descarga 
solo se enviaran un subconjunto de los mensajes almacenados 
en el encaminador y el resto se preservaran para rondas 
posteriores. Dicha técnica, llamada mezclador con estanque 
(Pool Mix), mejora el grado de anonimato en situaciones de 
tráfico fluctuante a base de compensar un momento de poca 
carga de tráfico con un mayor retraso en la entrega de los 
mensajes. Esta solución es ideal para aplicaciones que no 
tienen restricciones de entrega muy ajustadas, tales como el 
correo electrónico anónimo. 

En contraposición al modelo de mezclador por lotes está el 
mezclador continuo [10], en el que los usuarios generan un 
retardo aleatorio por cada mensaje que incluyen en la cabecera 
del mensaje. El mezclador almacena el mensaje durante el 
tiempo especificado y entonces lo reenvía. La ventaja de este 
método es que los propios usuarios controlan el tiempo límite 
de transferencia de la información. Este modelo funciona bien 


en situaciones de tráfico relativamente estable y constante. Sin 
embargo, en caso de que se produzcan períodos de tráfico 
reducido, el grado de anonimato de este modelo es bajo. 
Tanto el mezclador continuo como el de estanque son 
vulnerables a ataques N — 1 consistentes en la alteración 
del flujo de N — 1 mensajes con el objetivo de poder trazar 
un mensaje concreto. Para el caso del mezclador continuo el 
atacante debe ser capaz de bloquear la entrada de mensajes 
al encaminador, mientras que para el mezclador de estanque 
tendría que inyectar mensajes marcados que provocaran una 
descarga controlada del mezclador. Para mitigar el efecto de 
este ataque, [11] propone que cada encaminador tome la 
decisión acerca del siguiente nodo sobre el que continuar la 
ruta, pudiendo incluso llegar a decidir añadir tráfico falso sobre 
rutas falsas. De hecho, las técnicas de tráfico falso son una 
buena manera de prevenir dicho problema (ver sección V). 


IV-B. Redes de mezcladores 


Para incrementar el grado de anonimato de un sistema 
mezclador, los enrutadores mezcladores suelen combinarse 
formando una red de mezcladores. De esta manera, puede 
llegar a preservarse el anonimato de los usuarios aún y cuando 
algunos nodos de la red sean comprometidos. 

Tenemos dos tipologías básicas: Cascadas y mezcladores 
de Ruta Libre. En una Cascada, la ruta o rutas que siguen 
los mensajes son preestablecidas. En un mezclador de Ruta 
Libre, el camino a seguir por cada mensaje puede seguir una 
ruta independiente. 

Una ventaja de las Cascadas sobre los mezcladores de Ruta 
Libre es el hecho de que tienden a concentrar más tráfico 
por sus rutas, lo que aumenta el grado de anonimato en las 
mismas. No obstante, en una Cascada un adversario puede 
llegar a conocer exactamente qué mezcladores debe controlar 
para trazar a un usuario en particular. Por tanto, no hay 
una topología mejor que las otras. Los sistemas [11], [23], 
[22] implementan el modelo de mezcladores de Ruta Libre, 
mientras que [1], [20], [14], [24], [18], [21], [17], [19], [3], 
[8], [9], [6], [15], [12] se ajustan al modelo de Cascada. 

Por otro lado, existen modelos de mezcladores combinados 
que tratan de obtener las ventajas de las dos opciones, como 
el establecimiento de múltiples Cascadas libres. 

Los sistemas de Cascada establecen una única ruta anónima, 
normalmente la más eficiente, sobre la que pasan todos los 
mensajes entre fuente y destino. Si se aplican las técnicas 
de un mezclador, ello puede ser suficiente para garantizar 
el anonimato de las transmisiones. Sobretodo considerando 
el hecho de que cualquier mensaje emitido a través de una 
MANET tiene una naturaleza multicast, lo que aumenta el 
conjunto de anonimato de los posibles receptores del mensaje. 

Sin embargo, en caso de ataque N — 1 un adversario global 
podría llegar a trazar una buena parte de la ruta analizando la 
evolución del tráfico en la red. Para dificultar dicho seguimien- 
to, hay sistemas que extienden la ruta más allá de su destino 
o que introducen rutas falsas (ver apartado IV-C). Por otro 
lado, el establecimiento de una única ruta debilita la seguridad 
del sistema resultante al hacerlo vulnerable a ataques del tipo 
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rushing (en los que el adversario trata de enviar mensajes de 
descubrimiento de la ruta antes que el nodo fuente para tratar 
de «apropiarse» de la ruta) y a intrusiones de un adversario 
sobre uno de los nodos de la ruta. 

Por ello, últimamente se están incorporando más sistemas 
MANET que permiten el establecimiento de circuitos a través 
de varias rutas. 


IV-C. Multicast anónimo 


En una red Ad Hoc todos los mensajes pueden ser consider- 
ados de tipo broadcast, ya que éstos pueden ser interceptados 
por cualquier nodo dentro del área de recepción de la señal 
electromagnética. Por tanto, todo mensaje enviado a través de 
dicho tipo de redes debe ser securizado y anonimizado en la 
medida de lo posible. 

De cara a anonimizar los mensajes, una primera medida 
a tomar es eliminar o distorsionar cualquier referencia iden- 
tificativa a bajo nivel, es decir, modificando las direcciones 
MAC de los mensajes y por ejemplo, insertando una sucesión 
de 1”s como direcciones fuente y destino (lo que en 802.11 es 
indicativo de dirección multicast). 

En función de la intencionalidad del emisor, podemos 
distinguir los siguientes tipos de mensaje: 


e Multicast: mensajes dirigidos a todos los nodos en el rango 
de alcance directo. En su mayoría se trata de mensajes 
utilizados para iniciar el descubrimiento y/o mantenimiento 
de rutas. En este caso se trata de mensajes que contienen 
una parte pública (inteligible para cualquier adversario) y 
otra privada (utilizada para incorporar parámetros privados 
de establecimiento de ruta con el nodo destino). 

e Unicast: mensajes dirigidos a un nodo en concreto. Son los 
más utilizados una vez se ha establecido una ruta. Ideal- 
mente se trata de mensajes completamente incoherentes e 
indistinguibles (tanto en su tamaño como contenido) por 
cualquier nodo que no sea aquel al que el mensaje va 
dirigido. Por razones de eficiencia, dichos mensajes también 
pueden llegar a incorporar una parte pública indicando el 
nodo sobre el que va dirigido el mensaje. Sin embargo, 
dicho parámetro de direccionamiento debería ser anónimo 
- es decir, sólo reconocible por el destino del mensaje. 
Para evitar que nodos externos a la red puedan reconocer la 

parte pública de los mensajes, se puede establecer una clave 
que permita codificar todos los mensajes de la MANET de 
manera global. Normalmente, por razones de eficiencia, dicha 
clave global será una clave simétrica. Sin embargo, se ha de 
tener en cuenta que dicha medida sólo será efectiva mientras 
que no haya ningún intruso en la red. 

Para minimizar el impacto que pueda tener la presencia 
de intrusos se recomienda tratar de minimizar la información 
topológica que pueda tener cualquier nodo de la red. Por esta 
razón - y también por razones de eficiencia -, los algoritmos 
de descubrimiento reactivos (que establecen la ruta de forma 
dinámica) acostumbran a ser más populares que los proactivos 
(en los que algunos nodos de la red son periódicamente 
alimentados con información topológica por parte del resto 
de nodos, ver [9] y [8])). 


En este sentido es preferible evitar sistemas que apliquen 
técnicas de Onion Routing (ver Chaum [5]) para el envío 
de los mensajes anónimos. Ello es debido a que, para la 
aplicación de dicha técnica, el nodo fuente requiere codificar 
el mensaje a enviar utilizando N claves, una para cada nodo 
por los que debe pasar el mensaje. Por tanto, el nodo fuente 
debe conocer toda la ruta por la que debe pasar el mensaje 
(SDAR [3],SDDR [12])). 

Una alternativa a dicha técnica consiste en el establec- 
imiento de tablas de rutas de seudónimos asociadas a claves 
y seudónimos destino. Cuando un mensaje llega a un nodo 
proveniente de un seudónimo fuente, el mensaje es recodifi- 
cado y enviado al seudónimo destino que marca su tabla. El 
nodo fuente tiene marcado en la tabla cuál es el seudónimo 
del primer nodo por el que debe pasar el mensaje para 
llegar a su destino. Dichas tablas son generadas por cada 
nodo en el momento de establecer la ruta (ver ANODR [14], 
ARM [17], ANONDSR [18]) o bien renovadas de forma 
periódica (MASK [23]). 


V. INDETECTABILIDAD 


Típicamente las redes anónimas pierden robustez a lo largo 
del tiempo debido a que un análisis exhaustivo de las trazas 
de la red permite obtener información de los usuarios y las 
relaciones que hay entre ellos. Una forma de atacar la raíz 
de este problema es enmascarar los mensajes entre nodos de 
forma que un atacante externo no pueda distinguir cuando la 
red está enviando datos o ruido. 

Entre las técnicas más utilizadas para enmascarar los men- 
sajes destacamos: 


= Comunicaciones a ráfagas cortas (burst communica- 
tions). La transmisión de mensajes muy cortos es muy 
difícil de detectar por los usuarios externos a la misma. 
Es por ello que este tipo de transmisiones se utilizan para 
enviar la información de control más sensible de la red. 

= Envío de mensajes ficticios (dummy data). Su objetivo 
es conseguir un flujo constante en la red y que el tipo 
de tráfico (real o falso) sea indiscernible a ojos de un 
atacante. 

= Modulación por espectro ensanchado (spread spec- 
trum). Las transmisiones por espectro ensanchado se 
caracterizan porque la información es enviada a través 
de un ancho de banda mucho más amplio que el mínimo 
requerido. Las técnicas más usadas son los sistemas de 
secuencia directa y los sistemas de salto de frecuencia. 
La ventaja de estos sistemas es que la señal es muy difícil 
de detectar para usuarios que desconozcan la técnica y 
la codificación usada para la transmisión del señal. 

= Esteganografía. Los métodos esteganográficos permiten 
esconder un mensaje dentro de un flujo de comunicación 
cualquiera de la red, de forma que solo el receptor 
legítimo pueda extraer la información del canal. Para el 
resto de usuario el mensaje es invisible. 

De las técnicas para enmascarar mensajes, las más sencilla 

y usada es la de envío de mensajes ficticios. Los mensajes 
ficticios pueden ser insertados en la entrada o salida de los 
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mezcladores. Normalmente la inserción en la salida provee 
mayor anonimato y menor retraso debido a que el mezclador 
puede regular de forma más precisa la introducción de men- 
sajes ficticios en la red según el estado del tráfico [14]. Sin 
embargo, en el caso del ataque N—1 la inserción en la entrada 
del mezclador puede ofrecer un mayor nivel de protección. 

Cuando tratamos sobre redes de mezcladores, los Mensajes 
Falsos pueden atravesar diversos encaminadores, tal como 
hace el resto de mensajes. El camino a atravesar se determina 
de forma aleatoria y normalmente termina en el encaminador 
que lo generó. Ello permite llegar a detectar ataques del tipo 
N — 1 y actuar en consecuencia. 

En el entorno de redes Ad Hoc, en el que el uso de recursos 
es muy limitado, el uso de dicho tipo de mensajes debe 
ser realmente minimizado. Sin embargo, también tenemos la 
ventaja de que un solo mensaje Falso extiende el conjunto 
de anonimato entre los posibles receptores a todos los nodos 
vecinos del nodo que emite dicho mensaje. 


vI. 


Los principales problemas abiertos en el área de anonimato 
para redes MANET son los siguientes: 


PROBLEMAS ABIERTOS 


= Anonimato de los sujetos: Uno de los retos principales 
en esta área consiste en establecer un sistema de confi- 
anza que permita la localización y autenticación mutua 
de nodos que toman la identidad como atributo para 
seleccionar con quien establecer una comunicación, sin 
que ello merme el anonimato de dichos nodos frente a 
usuarios externos. Por tanto, se requiere un protocolo de 
distribución de las claves iniciales del sistema que sea 
eficiente y seguro. 

= Métodos de incentivo: Debido a la limitada capacidad 
de los dispositivos deben establecerse mecanismos de 
incentivo y reputaciones para que los usuarios de una 
MANET estén dispuestos a proveer sus terminales como 
enrutadores de mensajes de terceros. Dichos métodos 
están basados en el establecimiento de protocolos de con- 
fianza distribuida, cuyo desarrollo en entornos anónimos 
es un reto aun no resuelto. 

= Desvinculación de mensajes: Área de investigación con- 
tinua para conseguir protocolos que resulten en una 
mayor eficiencia y robustez frente a análisis exhaustivo 
del tráfico. 

= Indetectabilidad: Área poco explotada cuya integración 
con el resto de técnicas a través de soluciónes cross-layer 
podría reforzar el anonimato de los sistemas resultantes. 
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Resumen—Los motores de búsqueda de Internet crean perfiles 
de sus usuarios con la finalidad de ofrecerles un servicio más 
personalizado. En el año 2006, el escándalo AOL, motivado por 
la publicación de las consultas de 658.000 usuarios, puso en duda 
la correcta protección de esta información y causó preocupación 
a los usuarios. De ahí que hayan aparecido numerosas propuestas 
para proteger la privacidad de los usuarios, la más importante 
de las cuales es la recuperación de información con privacidad 
(en inglés, Private Information Retrieval o PIR). Sin embargo, las 
dificultades de implementación que presenta el PIR estricto hacen 
necesaria su relajación en la práctica. Esta relajación del PIR 
se conoce como recuperación de información con privacidad de 
usuario (en inglés User-Private Information Retrieval - UPIR). En 
la mayoría de protocolos UPIR, varios usuarios colaboran entre 
ellos para proteger su privacidad. Las últimas propuestas imple- 
mentan los sistemas UPIR sobre redes sociales, aprovechando su 
estructura y evitando el coste de mantenimiento de una red P2P. 
Aún así, la sobrecarga de la red o la pérdida de privacidad frente 
a otros usuarios sigue siendo común. A continuación presentamos 
tres protocolos de UPIR basados en redes sociales y distintas 
técnicas criptográficas. 

Index Terms—Recuperación de información con privacidad 
(Private information retrieval), Recuperación de información con 
privacidad de usuario (User-private information retrieval), Redes 
sociales (Social networks), Protocolos criptográficos (Cryptograph- 
ic protocols). 


I.. INTRODUCCIÓN 


El objetivo de la recuperación de información con privaci- 
dad (en inglés Private Information Retrieval - PIR) es permitir 
a un usuario recuperar un objeto de una base de datos sin que 
posteriormente se pueda conocer de qué objeto se trataba. En 
la literatura de PIR (ver los documentos seminales [1], [2] y el 
resumen [3]) la base de datos se modela como un vector, y se 
supone que el usuario quiere recuperar el ¿-ésimo componente 
del vector, manteniendo el índice ¿ oculto ante la base de datos. 
Aunque esta visión de los protocolos PIR permite desarrollos 
teóricos, se basa en muchas suposiciones que dificultan su 
desarrollo práctico: 


= En general, la base de datos no puede modelarse como 
un vector en el cual el usuario conoce la ubicación física 


1 del objeto que le interesa (por ejemplo, pensemos en 
un usuario consultando un motor de búsqueda). 
= Si la base de datos contiene n objetos, los protocolos 
PIR teóricos tienen una complejidad O(n) [1], [2]: el 
protocolo debe “acceder” a todos los registros para evitar 
dar alguna pista al servidor sobre el valor de 1; esto es 
inasequible para grandes bases de datos o motores de 
búsqueda [4]; 

= Se supone que el servidor de la base de datos coopera 
en el protocolo PIR; no obstante, es el usuario quien 
está interesado en su propia privacidad, mientras que la 
motivación del servidor de la base de datos es dudosa; 
de hecho, PIR parece poco atractivo para la mayoría de 
compañías que ofrecen bases de datos consultables, ya 
que limita su habilidad para crear perfiles de usuario. 

Por las razones anteriores, parece ser necesario relajar las 
suposiciones del PIR por el bien de su aplicación práctica. A 
continuación repasamos algunas de las relajaciones propuestas. 

En primer lugar, notemos que los sistemas de encami- 
namiento por capas (onion-routing) como Tor [5] no tienen 
por objetivo la recuperación de información con privacidad. 
Estos sistemas protegen el transporte de los datos, pero no 
ofrecen una protección punto a punto a nivel de aplicación. 
Siempre que un motor de búsqueda o un servidor de base de 
datos pueda enlazar las consultas sucesivas sometidas por el 
mismo usuario (p.e usando galletas), podrá perfilar e identificar 
al usuario. Del mismo modo, los sistemas basados en hardware 
de confianza como [6], solo trasladan el problema de la base 
de datos a dicho hardware. 

En [7] se propone un sistema llamado GooPIR, en el cual 
un usuario enmascara su consulta real añadiéndole k — 1 
consultas falsas y luego sometiendo la consulta enmascarada 
resultante a un motor de búsqueda o una base de datos grande 
que no tiene por qué cooperar (de hecho, no tiene ni por 
qué saber que el usuario está intentando proteger su privaci- 
dad). Strictu sensu, GOOPIR no proporciona PIR como se 
ha definido anteriormente; más bien proporciona recuperación 
de información con h(k)-privacidad, en la que se esconde 
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la consulta real dentro de un conjunto de k consultas de 
entropía al menos h(k). Este sistema funciona adecuadamente 
pero supone que las frecuencias de las palabras y frases que 
aparecen en una consulta son conocidas y están disponibles: 
para mayor privacidad, las frecuencias de las consultas reales y 
falsas deben ser similares, de modo que la incertidumbre h(k) 
del motor de búsqueda sobre la consulta real sea máxima. 

TrackMeNot [8] es otro sistema práctico basado en un 
principio diferente: en lugar de someter una única consulta 
enmascarada para cada consulta real, como hace GooPIR, 
esconde la consulta real del usuario en una nube de consultas- 
fantasma sometidas de forma automática en diferentes interval- 
os de tiempo a varios motores de búsqueda. Su funcionamiento 
es transparente para el usuario, dado que es una extensión 
del navegador y realiza las consultas cuando la actividad del 
usuario es baja. Aunque este sistema resulta práctico a pequeña 
escala, si su uso se generalizase, la sobrecarga introducida 
por las consultas-fantasma degradaría significativamente el 
rendimiento de los motores de búsqueda y las redes de comuni- 
cación. Además, los intervalos entre sumisiones de consultas- 
fantasma pueden ser diferentes de los intervalos entre consultas 
reales, lo que puede dar pistas al motor de búsqueda para 
identificar este último tipo de consultas. 

Crowds [9] propone proteger la privacidad de los usuarios de 
una red ocultando sus acciones mediante las de otros usuarios. 
Un usuario puede someter una consulta al motor de búsqueda o 
mandarla a otro usuario de la red. A su vez, éste puede someter 
la consulta o mandarla a otro usuario; y así sucesivamente, 
hasta que un usuario someta la consulta al motor de búsqueda. 
Una debilidad del sistema es que la entrada y salida de 
usuarios requiere un nodo central. Además, el reenvío de 
mensajes utiliza una probabilidad fija que permite identificar 
al usuario origen, ya que sus mensajes no se distribuyen 
uniformemente por la red. Tampoco hay ningún control sobre 
el envío de mensajes, siendo el sistema susceptible a ataques 
de denegación de servicio. 

Con la misma finalidad práctica, el sistema descrito en [10] 
oculta a los usuarios en una comunidad anónima de usuarios 
por pares (P2P). Un usuario somete consultas en nombre 
de sus vecinos anónimos y viceversa. Los usuarios en la 
comunidad P2P comparten claves simétricas de cifrado que 
utilizan para establecer canales confidenciales. De este modo, 
la base de datos conoce la consulta que se está recuperando 
(lo que se diferencia del PIR estricto), pero no puede obtener 
los historiales de búsqueda de los usuarios, ya que quedan 
difuminados entre los usuarios vecinos. Este enfoque tiene 
algunas ventajas: a diferencia de [7], no requiere conocer la 
frecuencia de todas las posibles palabras y frases que pueden 
ser consultadas, y, a diferencia de [8], no sobrecarga al motor 
de búsqueda con consultas-fantasma. Sobre la preservación de 
la privacidad del perfil del usuario respecto a la base de datos 
y a intrusos externos, el sistema [10] ofrece privacidad hacia 
los usuarios vecinos porque los vecinos son anónimos entre sí. 
Algunos inconvenientes del sistema son la necesidad de crear 
una red P2P anónima y la distribución de claves en dicha 
red, aunque en [10] se muestra como distribuir claves sin una 


tercera parte de confianza. 

En [11], se propone otro enfoque UPIR P2P. En este caso, 
el anonimato se consigue con la ayuda de un nodo central que 
pone en contacto a un grupo de n usuarios que quieren someter 
una consulta cada uno. Los usuarios ejecutan un protocolo 
de recuperación de consultas donde cada usuario recibe una 
consulta de uno de los restantes n — 1 usuarios, sin saber 
de qué usuario proviene. Cada usuario somete la consulta 
recibida al motor de búsqueda, y manda por difusión a todos 
los usuarios la respuesta obtenida. De este modo, los usuarios 
que publicaron la consulta pueden recuperar la correspondiente 
respuesta. Aunque este esquema preserva la privacidad del 
historial de consultas frente a los vecinos, tiene el defecto de 
que todas las respuestas son vistas por todos los vecinos, lo 
que es una desventaja respecto a los esquemas anteriormente 
citados. 

En [12] se presenta una alternativa al P2P UPIR basada en 
una red social. Un usuario que quiere hacer una consulta la 
envía a uno de sus vecinos de la red social. Este vecino puede 
someter la consulta directamente a la base de datos o mandarla 
a uno de sus vecinos; y así sucesivamente, hasta que uno 
de ellos someta la consulta. La respuesta a la consulta sigue 
el camino inverso hacia el usuario que la ha originado. Para 
proteger el anonimato del origen de la consulta, la propuesta 
distribuye las consultas uniformemente entre los usuarios. Una 
característica atractiva de este sistema es el uso de una red 
social existente como comunidad de pares, lo que facilita su 
implementación. Sin embargo, un problema de esta propuesta 
es que la consulta sometida es vista por todos los usuarios que 
la han aceptado, es decir, desde usuario origen hasta el usuario 
que la envía al motor de búsqueda. Algunos usuarios pueden 
preferir someter ciertas consultas directamente a un motor de 
búsqueda antes que revelárselas a sus amigos. 


LA. Contribución y plan de este artículo 


Presentamos protocolos criptográficos para recuperación de 
información con privacidad de usuario que reúnen las ventajas 
de [10] y [12], a la vez que mejoran sus puntos débiles. 

En la sección II se presentan las hipótesis y el objetivo de 
nuestro sistema. En la sección III se describe el funcionamien- 
to de nuestras propuestas y a su vez se comentan sus ventajas e 
inconvenientes. La sección IV contiene algunas conclusiones. 


II. HIPÓTESIS Y OBJETIVO 


Las redes sociales son un fenómeno en crecimiento [13]. 
Una red social es una comunidad de usuarios con intereses 
en común donde cada uno puede publicar o compartir infor- 
mación y servicios. Concretamente, seguiremos el concepto 
de red social descrito en [14]. Esta propuesta no requiere 
la existencia de un nodo central. Así, los usuarios están 
conectados directamente entre ellos o por medio de otros 
usuarios que actúan como intermediarios. Cada usuario puede 
estar en línea o desconectado en un momento dado. Por ese 
motivo, debemos suponer que se trata de una red ad hoc. 

Consideraremos además que una red social es una red 
abierta a la exploración. Esto significa que los usuarios cono- 
cen la topología de la red social (o gran parte de ella). 
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Por consiguiente, los usuarios son capaces de calcular las 
distancias entre ellos (número de saltos entre cada par de 
usuarios). 

Sea U, un usuario perteneciente a una red social RS y 
(N1,..., Nz) su conjunto de vecinos (un vecino es una 
relación directa en la red social). U;, quiere someter una 
consulta a un motor de búsqueda sin que éste cree un perfil 
detallado suyo, o lo que es lo mismo, U, quiere mantener 
su privacidad. Con esta finalidad, U, obtiene la ayuda de los 
demás usuarios de la red social para que sometan su consulta 
en su nombre. 

El objetivo de nuestra propuesta es proteger la privacidad 
de los usuarios conectados a una red ad hoc frente a un motor 
de búsqueda y también frente a los otros usuarios de la red 
social. Para conseguirlo hacemos uso de la criptografía. 


III. PROTOCOLOS CRIPTOGRÁFICOS PARA OFUSCACIÓN 
DEL PERFIL DE USUARIO 

A continuación vamos a presentar tres esquemas distintos: 

= Clave pública. 

= Clave simétrica. 

= Esquema de umbral. 

En todos los esquemas vamos a considerar a un usuario U,, 
perteneciente a una red social RS, que quiere someter una con- 
sulta q a un motor de búsqueda. Los usuarios de RS conocen 
la topología de la red pero solamente se pueden comunicar 
con sus relaciones directas. Nótese que el funcionamiento y 
mantenimiento de la red social están fuera de los objetivos de 
este trabajo. 


TILA. Clave pública 


En esta propuesta cada usuario de la red social dispone de 
un par de claves (clave pública PK - clave privada SK) y 
del correspondiente certificado digital. 

Los usuarios que quieren entrar en el sistema mandan 
peticiones a sus vecinos pidiéndoles su certificado digital. Esta 
petición se propaga por la red hacia el resto de usuarios hasta 
un máximo de saltos. La primera vez que el usuario utiliza el 
sistema debe esperar a recibir su primer certificado para poder 
participar. 

Cuando un usuario quiere someter una consulta, la manda 
junto con una clave simétrica, obtenida aleatoriamente, por el 
camino más corto hacia otro usuario de quien desea ayuda. 
Esta información está cifrada con la clave pública del desti- 
natario, de modo que sólo éste puede conocer el contenido 
del mensaje. La respuesta a la consulta llega al usuario origen 
cifrada con la clave simétrica adjunta a la consulta. 

IHIFA1. Acceso al sistema: Sea c, un mensaje definido e 
identificable de nuestro sistema que se utiliza como petición de 
certificados y sea Cc, su respuesta. Cada usuario mantiene una 
tabla de certificados recibidos de otros usuarios, de ahora en 
adelante denominada 7. Cada fila de 7 representa a un usuario 
y contiene su identificador ¿d (el identificador de su certificado 
digital), su clave pública P Kg, su certificado digital CERT;q 
y el contador de disponibilidad count. Para evitar la saturación 
de la red, c, contiene un contador de saltos, T'I'L. En cada 


salto se decrementa el TT'L y, mientras sea mayor que cero, 
Cy es reenviado. 

Si el usuario U;, quiere entrar en el sistema, ejecutará el 
siguiente protocolo: 


= Cada cierto intervalo de tiempo w, U;, manda a todos sus 
vecinos una petición C,.. 
= Cuando U; recibe una c¿: 
e Comprueba la validez del certificado recibido. 


o Sies válido lo agrega a 7. Si ya existe el usuario 
en 7, incrementa su contador de disponibilidad 
count. 

o Si el certificado no es válido, lo ignora. 


= Al finalizar el periodo w, todos los contadores de disponi- 
bilidad de los usuarios son decrementados con el fin de 
mantener actualizada la tabla con los usuarios que están 
en línea. Cuando el contador de disponibilidad de un 
usuario llega a O, el usuario es eliminado de la tabla. Si 
todos los usuarios son borrados de 7, U; queda aislado. 


Cuando un usuario recibe una petición c, realiza los pasos 
siguientes: 


= Responde con su certificado al vecino que le ha enviado 
Cro 

= Decrementa el T'T'L de c,.. 

= Siel TT'L > 0 reenvia c, a sus vecinos (excepto al 
vecino que le ha enviado c,.). 


HT-A2. Sumisión de una consulta: Cuando el usuario U;, 
con identificador ¿d;, quiere someter la consulta q a un motor 
de búsqueda, ejecuta el protocolo siguiente: 


= Escoge aleatoriamente a un usuario de su tabla 7. Sea 
Uy el usuario seleccionado por U; e id; su identificador. 

= Obtiene una clave simétrica sk de forma aleatoria. 

= Crea el mensaje M = qía, Epk,(q, sk), ¡dy 
donde q;a es el identificador de la consulta; Ep x,(q, sk) 
son la consulta q y la clave simétrica sk cifrados bajo 
la clave pública PK y del destinatario; ¿d ; es el identifi- 
cador del destinatario. 

= Inicia el temporizador t. 

= Manda el mensaje M al vecino más cercano a Uf, por 
ejemplo U;. Uj manda el mensaje a su vecino más 
cercano a Uf, y así sucesivamente hasta que el mensaje 
llega a Uf. De este modo, M llaga a Uf por el camino 
más corto. 

= Espera un tiempo máximo t hasta recibir respuesta del 
usuario Uf: 


e Así que la respuesta llega, finaliza el protocolo. 
e Si la respuesta no llega en este tiempo, vuelve a 
ejecutar el protocolo. 


Cuando un usuario recibe una consulta de otro usuario, 
ejecuta los siguientes pasos: 
= Sies el destinatario del mensaje recibido: 


e Descifra el mensaje M = qía, Dsx,(q, sk), id y 
e Envía la consulta q al motor de búsqueda. 
e Cifra la respuesta del motor de búsqueda con sk. 
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e Manda la respuesta al usuario origen siguiendo el 
camino inverso. 


= Si la consulta va destinada a otro usuario Uf, la reenvía 
a su vecino más cercano a U,. 


IIFAS. Análisis del protocolo: Este esquema permite 
conocer el número de saltos que hace una consulta hasta que 
llega a su destinatario, con lo que se puede determinar el 
tiempo estimado que tardará [15]. Si se quiere reducir este 
tiempo, el usuario puede mandar la consulta a un usuario más 
cercano, aumentando la usabilidad del sistema, pero reducien- 
do la privacidad, pues el tamaño del grupo será inferior. 

Además, el esquema no requiere que los usuarios acuerden 
previamente una clave común. Sin embargo, el uso de claves 
públicas obliga a cada usuario a mantener un gran número 
de certificados digitales, concretamente uno por cada usuario 
conocido en la red. 

Como se ha comentado en la sección I, tan importante como 
la privacidad frente al motor de búsqueda es la privacidad 
frente a otros usuarios de la red. Al encaminar tanto la consulta 
como su respuesta salto a salto, el origen de la consulta se 
mantiene oculto ante los otros usuarios. Sin embargo, sí se 
conoce la identidad (id ;) del destinatario. 


HI-B. Clave simétrica 


Nuestra segunda propuesta pretende reducir el número 
de certificados que cada usuario tiene que almacenar, y a 
la vez proteger el anonimato de los usuarios mediante la 
formación de grupos. Los usuarios de cada grupo escogen 
una clave en común gx de forma distribuida (sin autoridad 
central) siguiendo el esquema propuesto en [10], que usa un 
diseño combinatorio llamado configuración para incrementar 
la disponibilidad en el sistema y reducir el número de claves 
requeridas. Las configuraciones permiten distribuir un número 
v de claves entre b usuarios, con 1 < v < b(b— 1)/2, de tal 
modo que cada usuario recibe el mismo número de claves y 
cada clave es compartida por el mismo número de usuarios. 

IHI-B1. Acceso al sistema: Cuando el usuario U, quiere 
formar un grupo ejecuta las siguientes acciones: 


= Publica que quiere formar un grupo de g usuarios. 
= Acepta peticiones hasta que recibe gy — 1. Por cada 
petición aceptada, U¿ manda un mensaje de confirmación. 


Los vecinos de U; interesados en formar parte del grupo 
le mandan un mensaje g,. Si un vecino U, es aceptado en el 
grupo, recibe un mensaje de confirmación y posteriormente 
publica que forma parte de un grupo con U;. Desde ese 
momento, los vecinos de U; pueden intentar unirse al grupo 
mandando una petición g, a U;, por el camino inverso, esto 
es, pasando por U. 

Una vez el grupo está completo, los usuarios acuerdan 
una clave simétrica y privada común (9) con el algoritmo 
distribuido [10]. Esta clave permitirá a los usuarios del grupo 
comunicarse de forma segura entre ellos. 

Notese que los vecinos de U;, en el grupo son sus vecinos 
en RS que también pertenecen al grupo. 


IIF-B2. Sumisión de una consulta: Cada usuario puede 
formar parte de varios grupos. Para someter una consulta, 
escoge uno de estos grupos y repite el protocolo de la sec- 
ción IH-A2, sustituyendo PK por g,; y enviando el mensaje 
a todos sus vecinos de RS pertenecientes al grupo, en lugar de 
a un usuario concreto. El mensaje enviado contiene la misma 
información que en el protocolo de la sección II-A2 menos 
el identificador del destinatario, pues en este caso no es un 
usuario concreto. Esto es, M = q;a, Ey, (q, sk). 

Cada usuario que recibe una consulta realiza los pasos 
siguientes: 


= Reenvía la consulta a sus vecinos del grupo. 
= Decide aleatoriamente si responde a la consulta o no. 


e Si decide responder la consulta, ejecuta los pasos 
siguientes: 


Descifra el mensaje M = qia, Dy, (q, sk). 
Somete la consulta q al motor de búsqueda. 
Cifra la respuesta del motor de búsqueda con sk. 
Envía la respuesta por difusión a sus vecinos del 
grupo. 
e Si decide no responder la consulta, ignora la peti- 
ción. 

HIFB3. Análisis del protocolo: En este esquema un 
usuario puede formar parte de varios grupos. Por ello, el 
usuario tiene que almacenar las claves simétricas de cada 
grupo al que pertenece. El hecho de guardar solamente una 
clave simétrica por grupo, en lugar de una clave pública y 
un certificado por cada usuario conocido, reduce el almace- 
namiento requerido con respecto al esquema de clave pública. 

Sin embargo, el uso del grupo también supone una pérdida 
de privacidad, puesto que todos los usuarios del grupo conocen 
la consulta sometida, aunque no sea identificable su origen 
(los emisores de las llamadas “vanity queries”, en las cuales 
un usuario se busca a sí mismo en el web, son obviamente 
identificables). 

El envío de mensajes por difusión permite que los usuarios 
permanezcan anónimos. Sin embargo, aunque a pequeña escala 
pueda funcionar bien, a medida que el número de usuarios 
crece, se degrada el rendimiento de la red de comunicación. 
Análogamente, el aumento de usuarios supone un mayor 
número de consultas mandadas al motor de búsqueda (nótese 
que cada consulta puede ser sometida por varios usuarios del 
mismo grupo), ocasionando una posible sobrecarga. 

La recepción de varias respuestas a su consulta permite al 
usuario comprobar la veracidad de las mismas. Si un usuario 
devuelve una respuesta falsa a otro usuario, la respuesta falsa 
podrá ser detectada si el resto de respuestas son correctas. 

La formación del grupo es un proceso que puede resultar 
costoso. Primero se deben reunir suficientes usuarios y poste- 
riormente acordar una clave común. Este proceso sería poco 
usable si se tuviera que formar un grupo por cada consulta 
a someter. En cambio, como el grupo puede permanecer 
formado durante mucho tiempo, el coste de su formación 
puede considerarse aceptable. 


O0oOoOoOo 


156 


HI-C. Sistema de umbral 


Esta última propuesta pretende solucionar los problemas de 
degradación de la red de comunicación y la sobrecarga del 
motor de búsqueda que presenta el esquema de clave simétrica 
mediante un criptosistema de umbral (t, 1)-ElGamal [16]. En 
un esquema de umbral (+, 1), un conjunto de | usuarios acuerda 
una clave pública común PK y cada usuario recibe una parte 
de la clave secreta SK;, de tal modo que cualquier subconjunto 
de t usuarios puede descifrar un mensaje cifrado con PK, pero 
menos de t£ usuarios no pueden. 
Cuando un usuario quiere someter una consulta q, escoge 
uno de los grupos a los que pertenece. A continuación cifra 
la consulta q y la clave secreta sk con la clave pública PK 
del grupo, y envía el criptograma obtenido a un vecino en RS 
perteneciente a ese grupo. El vecino lo descifra y, si no puede 
leer el mensaje, lo manda a otro vecino. Y así sucesivamente 
durante t saltos. La respuesta a la consulta vuelve por el 
camino inverso hacia el usuario que ha originado q. 
HI-C1I. Acceso al sistema: Cuando un usuario quiere 
entrar en el sistema ejecuta el protocolo de la sección MI-B1, 
con la única diferencia de que utiliza el sistema presentado 
en [16] para obtener la clave pública de cifrado y las partes 
de la clave privada de descifrado. 
Igual que en el esquema anterior, cada usuario puede formar 
parte de varios grupos y sus vecinos en cada grupo son sus 
vecinos en RS que también pertenecen a ese grupo. Además, 
cada usuario tiene que almacenar la clave pública y su parte 
de la clave privada de cada grupo al que pertenece. 
III-C2. Sumisión de una consulta: Si el usuario U;, quiere 
enviar una consulta q al motor de búsqueda ejecuta los pasos 
siguientes: 
= Escoge un grupo G y un vecino U, € G 
= Obtiene una clave simétrica sk. 
= Manda a U; el mensaje M = qa, G, Epx¿(q, sk), 
donde PK'¿ es la clave pública del grupo G. 

= Inicia un temporizador y espera la recepción de la re- 
spuesta. Si el temporizador expira sin recibir la respuesta 
repite el proceso con otro grupo y vecino. 

Un usuario al recibir una petición de consulta ejecuta los 
siguientes pasos: 

= Descifra el mensaje recibido m = qa, G, Dsk 4 ¿(q, sk), 

donde S Kg ¡ es la parte de la clave secreta del grupo G 
que posee el usuario. 

= Si m es un mensaje válido: 

e Envía la consulta q al motor de búsqueda. 

e Cifra la respuesta del motor de búsqueda con sk. 

e Manda la respuesta al usuario origen por el camino 
inverso. 

= Sim no és un mensaje válido, lo reenvía a un vecino en 

RS perteneciente a G. 

HEC3. Análisis del protocolo: En este esquema todos 
los usuarios permanecen anónimos. Sin embargo, al utilizar 
un criptosistema de umbral (t, /)-ElGamal, sabemos que son 
necesarios t saltos para poder descifrar la consulta, lo que 
nos puede dar una idea aproximada del origen de la consulta. 


Podemos incrementar la incertidumbre permitiendo que el 
usuario origen descifre la consulta cifrada una primera vez o 
no. De éste modo no se podrá saber con certeza si el mensaje 
ha hecho t o t— 1 saltos. 

Gracias a que se ha evitado el envío de mensajes por 
difusión, nuestro sistema no sufre de saturación. A su vez, 
esto nos permite saber el tiempo de respuesta estimado, ya 
que se conoce el número de saltos que hace un mensaje [15]. 

Un nuevo aspecto interesante es la imputación de revelación 
de clave. En el esquema de clave simétrica, los usuarios 
compartían una misma clave. En caso de que ésta fuera 
revelada no se podía saber quién había sido. Este último 
esquema permite saber qué usuarios han revelado su clave 
secreta, pues cada uno tiene una distinta. 


IV. CONCLUSIONES 


Los tres protocolos presentados (clave pública, clave 
simétrica, y sistema de umbral) garantizan la protección del 
perfil de los usuarios frente al motor de búsqueda y frente 
al resto de usuarios de la red social. El protocolo basado 
en criptografía de clave pública permite conocer el número 
de saltos que realizará la consulta, de manera que se puede 
estimar el tiempo de respuesta. El protocolo de clave simétrica 
es adecuado en un entorno con atacantes que manipulan las 
respuestas del motor de búsqueda. En este caso, el usuario 
que ha originado la consulta recibe varias respuestas, y puede 
detectar una manipulación si las respuestas no coinciden. 
Finalmente, el protocolo basado en un esquema de umbral 
reduce el número de claves públicas que se deben almacenar 
y no sobrecarga al motor de búsqueda. 

Los protocolos presentados pueden ser implementados en 
un mismo sistema como extensión de un navegador web. El 
usuario, según sus necesidades, escogerá utilizar uno u otro. 
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Resumen—_Los procesos de auditoría transparentes son impor- 
tantes en las elecciones electrónicas. Las mixnets universalmente 
verificables ayudan a conseguir esta transparencia generando 
pruebas criptográficas que pueden ser verificadas por un auditor. 
En este artículo presentamos un sistema eficiente de verificación 
de mixnets que consigue un buen nivel de precisión a la vez que 
preserva totalmente la privacidad de los votantes. Además, se 
propone un método para cifrar los votos que mejora la capacidad 
de detección de errores en el cifrado a la vez que se mantiene el 
rendimiento de la mixnet. 


I.. INTRODUCCIÓN 


Cuando una elección se lleva a cabo de forma electrónica, el 
principal problema que surge es cómo implementar un proceso 
de auditoría transparente. En las elecciones tradicionales, 
existen auditores independientes y observadores que pueden 
supervisar directamente el proceso de la elección en tiempo 
real, especialmente el proceso de apertura de las urnas y 
el recuento de los votos. Cuando el recuento se realiza de 
forma electrónica (por ejemplo, el descifrado y recuento de los 
votos), la supervisión del proceso lógico durante su ejecución 
en la máquina es prácticamente imposible, ya que no puede 
ser monitorizado directamente por el humano como en las 
elecciones tradicionales. Así pues, es muy importante que un 
sistema de voto electrónico proporcione métodos de auditoría 
transparentes para poder verificar su correcto funcionamiento. 

Dado que en el voto electrónico los resultados se pueden 
verificar haciendo un recuento paralelo de los votos (de la 
misma forma que cuando la elección se realiza de forma 
tradicional), la dificultad del proceso de auditoría reside en 
la verificación de la correcta apertura de los votos, es decir, 
el proceso de descifrado. 

Una posible solución consiste en permitir que los auditores 
u observadores instalen programas en el sistema para moni- 
torizar la plataforma de voto. El problema reside en que estos 
programas de monitorización deberían ser también monito- 
rizados a su vez, dado que el proceso de descifrado podría 
ser vulnerable a ellos. Como podemos ver, este procedimiento 
introduce un bucle infinito que no tiene fácil solución (who 
watches the watchmen?). 

Otra solución alternativa podría ser auditar el proceso de 
descifrado monitorizando la información de logs generada 
durante su ejecución. No obstante, si asumimos que el proceso 
de descifrado puede ser comprometido, la información de 
logs podría ser manipulada a su vez para ocultar prácticas 
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maliciosas. Es más, la información de logs que proporciona 
el proceso de descifrado debe ser limitada para preservar la 
privacidad de los votantes (por ejemplo, no se debería registrar 
la relación entre un contenido descifrado y un voto cifrado si 
el último está conectado a la identidad de un votante). 


En 1995, Sako y Kilian [SK95] introdujeron el concepto 
de verificabilidad universal en su propuesta de un proceso de 
descifrado de votos basado en una mixnet. Esta propiedad con- 
siste en proporcionar medios a cualquier auditor u observador 
para verificar el correcto descifrado de los votos, utilizando 
pruebas criptográficas que son generadas por el proceso de 
descifrado. 


Una mixnet está compuesta por uno o varios nodos que 
mezclan los mensajes de entrada utilizando una permutación 
cuyo valor es guardado en secreto. Los nodos de la mixnet 
también realizan un proceso de transformación que modifica 
los valores de los cifrados de los votos en la entrada para evitar 
la correlación de las entradas y salidas (protegiendo así la 
privacidad de los votantes). Dado que esta transformación no 
permite asegurar a simple vista que los votos en la salida del 
nodo de la mixnet son los mismos que los votos en la entrada, 
es importante poder verificar el proceso de mixing y descifrado 
de un modo que preserve la privacidad de los votantes y la 
integridad de los votos. 


Desde que Chaum presentó la primera mixnet en 
1981 [Ch81], la búsqueda de métodos eficientes de verificación 
que no pongan en peligro el proceso de anonimización de 
los votos en el mixing (por ejemplo revelando la permutación 
secreta o los valores de recifrado) es una área muy fértil de 
investigación. Concretamente, la propiedad de verificabilidad 
universal es el propósito principal de las mixnets diseñadas en 
los últimos 15 años. 


En este artículo presentamos un método de verificación 
universal eficiente para mixnets de recifrado que tiene una 
gran capacidad de detección de modificaciones a la vez que se 
preserva la privacidad de los votantes. El artículo se estructura 
de la siguiente forma: en la sección II explicamos nuestra 
motivación para diseñar un nuevo sistema de verificación de 
mixnets, en la sección III se define el criptosistema utilizado 
para cifrar los votos, en la sección IV se presenta el nuevo 
método de verificación de mixnets, en la sección V se propone 
un sistema para cifrar los votos de forma eficiente, y las 
conclusiones del artículo se presentan en la sección VI. 
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TI. MOTIVACIÓN 


Generar pruebas criptográficas que permitan la verificación 
universal del proceso de mixing puede ser complejo, computa- 
cionalmente costoso, y puede poner en riesgo la privacidad de 
los votantes. 

Algunos sistemas de mixing verificable [SK95], [FS01], 
[Ne01], consiguen una gran precisión (buena capacidad de 
detección de comportamientos maliciosos) a la vez que preser- 
van la privacidad de los votantes, todo ello a costa de tener 
que realizar una gran cantidad de pruebas y verificaciones. 
Dado que estas pruebas y verificaciones suponen un gran 
coste computacional, estos sistemas resultan inadecuados para 
ser utilizados en elecciones reales con un gran número de 
votantes, ya que se ralentizaría el proceso excesivamente. Por 
esta razón, existen propuestas (por ejemplo en [BG02]) donde 
se utilizan estos sistemas para hacer un recuento paralelo de 
los votos al mismo tiempo que se usan métodos más rápidos 
(y menos precisos) para publicar los resultados provisionales 
de la elección. 

Para mejorar la eficiencia del proceso de mixing, otros 
sistemas se enfocan en la reducción del coste de las verifica- 
ciones, sacrificando así en parte la privacidad de los votantes, o 
reduciendo la precisión del proceso de auditoría a un nivel aún 
suficiente para un proceso electoral. Por ejemplo, la propuesta 
de Random Partial Checking (RPC) [JJRO2] sacrifica prin- 
cipalmente privacidad, mientras que la propuesta presentada 
en [Go02] preserva la privacidad de los votantes a costa de 
una reducción en la precisión y en la eficiencia, realizando más 
pruebas que ralentizan el proceso de verificación. En [BG02] 
se propone otro método que reduce la privacidad y precisión 
obtenidas a costa de la eficiencia, consiguiendo resultados que 
pueden resultar suficientemente buenos para un proceso de 
votación electrónica cuando se manejan grandes cantidades 
de votos. 

El sistema de verificación de mixing que se presenta en este 
artículo es muy eficiente (comparable a las propuestas más 
rápidas) a la vez que preserva completamente la privacidad 
del votante y consigue un nivel alto de precisión. 


TIT. CRIPTOSISTEMA 


En nuestra propuesta, los votantes usan el criptosistema 
ElGamal (parametrizado apropiadamente para tener seguridad 
semántica [Pf94], [TY98]) para cifrar los votos. El criptosis- 
tema se compone de tres parámetros públicos: p, q, y; una 
clave pública h; y una clave privada x, definidos del siguiente 
modo: 


= El módulo p es un primo seguro (safe prime), es decir, 
p=2q>+1 y q es un número primo. 

= yes un generador de G¿, el subgrupo de orden q de Z¿. 

= La clave privada x es un elemento de Z,, y la clave 
pública h se calcula como h = g* mod p. 


Para que los votos cifrados sean indistinguibles, las opciones 
de voto v se configuran de modo que todas provengan del 
conjunto de residuos cuadráticos, o del conjunto de residuos 
no cuadráticos modulo p. En el caso de que una opción de 


voto no encaje en el conjunto escogido se puede utilizar un 
relleno o padding. 

Las opciones de voto se cifran utilizando exponentes aleato- 
rios r pertenecientes a Zg: 

c=(v-h" mod p, g” mod p) = (c,, ca). 

Así, una opción de voto se puede recuperar a partir del 
cifrado como v = c1 - Cc,” mod p. 

Este criptosistema tiene ciertas propiedades interesantes que 
utilizamos en nuestro proceso de verificación de mixing, tales 
como el recifrado y la operación homomórfica de los votos 
cifrados (que veremos en la sección IV-C). 


IFA. Recifrado de los votos cifrados 


Gracias a las propiedades del criptosistema ElGamal, un 
mensaje cifrado puede ser cifrado de nuevo (recifrado) usando 
un nuevo valor de aleatorización sin necesidad de modificar el 
proceso de descifrado: si el voto cifrado es c = (uv - h” mod 
p,g” mod p) = (c,,c2), el recifrado se puede realizar como 
e” =(c,-h"" mod p, cz: g”" mod p) = (v-h"+"" mod p, g"+" 
mod p) = (ch, co), donde r” es un nuevo exponente aleatorio. 
El voto recifrado se puede descifrar como: v = c| -c4 ” mod 


Pp. 
IV. PROCESO DE MIXING Y VERIFICACIÓN 


IV-A. Breve descripción del método 


El método de verificación universal para mixnets de recifra- 
do que se presenta en este artículo combina las ventajas de la 
técnica RPC [JJRO02] con las de la propuesta de Optimistic 
Mixing [Go02]: la revelación parcial de la información se 
combina con pruebas calculadas a partir de la operación 
homomórfica de grupos de votos, consiguiendo así mejores 
niveles de privacidad, robustez y precisión que estos métodos. 

En un primer paso cada nodo de la mixnet mezcla y recifra 
los votos cifrados de entrada, guardando de forma secreta y 
segura los valores de permutación y recifrado aplicados a cada 
voto. Una vez que el último nodo ha mezclado y recifrado 
sus entradas, los votos, ya anonimizados, están listos para ser 
descifrados, pero antes de revelar su contenido se verifica que 
la mixnet ha realizado el proceso de forma correcta. En nuestro 
sistema suponemos que, en el caso de existir uno o más nodos 
maliciosos, éstos intentarán modificar el contenido de los votos 
que procesan para cambiar el resultado de la elección. 

En el proceso de verificación los votos cifrados en la entrada 
de cada nodo se dividen en varios grupos independientes según 
una organización aleatoria propuesta por un verificador (o 
auditor). Esta organización en grupos se realiza al final del 
proceso de mixing, antes del descifrado, para evitar que los no- 
dos puedan conocer información por avanzado que les permita 
falsear las pruebas. Entonces, cada probador - o nodo de la 
mixnet -, por turnos, proporciona al verificador la localización 
global a la salida del nodo de los votos pertenecientes a cada 
grupo definido en la entrada. 

La localización global a la salida de un nodo de los votos 
pertenecientes a un determinado grupo no revela la posición 
exacta de cada voto individual. Por ejemplo, el nodo probador 
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podría revelar a qué grupo pertenecen los votos a la salida 
asignándoles un valor numérico. 

Cuando el verificador divide los votos cifrados de entrada 
en grupos, multiplica los votos de cada grupo para obtener 
una Prueba de Integridad Entrante utilizando las propiedades 
homomórficas que se explican en la sección IV-C. Después 
de que el probador indique qué votos a la salida del nodo 
pertenecen a cada grupo definido en la entrada, el verificador 
puede multiplicar los votos que pertenecen a un mismo grupo 
para obtener una Prueba de Integridad Saliente. Para cada par 
PI Entrante/Saliente de cada nodo de la mixnet, el probador 
proporciona una prueba de conocimiento nulo para demostrar 
que la PI Saliente es el recifrado de la PI Entrante. 

Dado que cualquier auditor puede calcular las pruebas 
de integridad y verificar las pruebas de conocimiento nulo, 
con este método conseguimos el objetivo de verificabilidad 
universal. Además, gracias a que se proporciona información 
sobre grupos y no sobre votos individuales, se mantiene la 
privacidad de los votantes. 

En las próximas secciones se proporcionan detalles sobre 
como se generan los grupos, las pruebas de integridad y las 
pruebas de conocimiento nulo. 


IV-B. Creación de los grupos 


Cuando el proceso de verificación se inicia, el verificador 
define de forma aleatoria los grupos en los que se dividen los 
votos de entrada del primer nodo de la mixnet, enviando una 
matriz con los índices de las posiciones de los votos a agrupar. 
Dado que el tamaño de los grupos está predefinido (tal y como 
se explica al final de esta sección), la matriz tiene dimensiones 
gxn, donde n es el número de votos en cada grupo y g es el 
número de grupos. 

Para m = 6 votos de entrada: (01,2, U3,..., Ug |; UN Número 
de grupos yg = 3, y n = 2 votos por grupo, un ejemplo de 
matriz de agrupamiento podría ser: 


V3g  U6 
VI  U5 
V2 Va 


El probador, a su vez organiza, los votos de entrada si- 
guiendo el orden marcado por la matriz de agrupamiento para 
definir los votos de cada grupo (en este ejemplo, los votos en 
las posiciones 3 y 6 pertenecerán al primer grupo). Utilizando 
la información de permutación del mixing, el probador indica 
al verificador, para cada voto a la salida del nodo, cuál es el 
grupo al que pertenece. Como la información se proporciona 
siguiendo el orden de las salidas del nodo de la mixnet, es 
imposible correlacionar individualmente los votos de entrada 
y salida (sólo el grupo al que pertenecen). 

En los siguientes nodos de la mixnet los grupos de votos en 
la entrada se redefinen utilizando como referencia los grupos 
de salida del nodo previo. No se aconseja redefinir los grupos 
de forma aleatoria, dado que entonces un atacante podría 
analizar los votos pertenecientes a cada grupo en cada nodo 
y llegar a situar un voto en la salida de la mixnet en un 
grupo específico de votos en la entrada. De este modo se 
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Figura 1. Trazabilidad de un mensaje en la mixnet. 


conseguiría romper parcialmente la privacidad de los votantes, 
ya que la probabilidad de que un voto en la entrada de la 
mixnet estuviera en una posición cualquiera a su salida dejaría 
de ser 1/n. Para prevenir este ataque, se recomienda definir 
los nuevos grupos de entrada en un nodo escogiendo votos 
pertenecientes a diferentes grupos de salida del nodo anterior, 
de forma que los grupos del último nodo de mixing estarán 
compuestos por al menos un voto perteneciente a cada uno de 
los grupos definidos en el primer nodo. De este modo, para 
un atacante será imposible escoger un voto en la salida de la 
mixnet y trazar su ruta a través de los nodos para encontrar 
el voto correspondiente en la entrada, ya que todos los votos 
en la entrada tendrán la misma probabilidad de corresponder 
al voto en la salida, tal y como muestra la figura 1. 

Una propuesta para redefinir los grupos consiste en selec- 
cionar votos pertenecientes a distintos grupos de salida del 
nodo anterior de forma consecutiva. En el ejemplo de la 
figura 1 el primer grupo del segundo nodo (G1,2) está formado 
por un voto del primer grupo del primer nodo (Gl) y por uno 
del segundo (G2); el segundo grupo del segundo nodo (G3,4) 
está formado por un voto del tercer grupo del primer nodo 
(G3) y uno del cuarto (G4), y así sucesivamente. 

El tamaño de los grupos es importante a la hora de mantener 
la privacidad del votante: si son demasiado pequeños, la 
distribución de votos/grupos a la salida de la mixnet puede 
no ser la aconsejada en el párrafo anterior (cada grupo en 
el último nodo no está formado por al menos un voto de 
cada uno de los grupos definidos en el primer nodo). Además, 
el tamaño también influye en la probabilidad de detectar 
votos manipulados durante el proceso de mixing: cuanto más 
pequeño es el grupo, más alta es la probabilidad de detección 
de manipulaciones. Así pues, los grupos deben definirse de una 
forma adecuada para conseguir el nivel más alto de detección 
sin comprometer la privacidad de los votantes. 

Si t es el número de nodos de la mixnet (al menos dos) 
y m el total de los votos, el número mínimo de n votos que 
debe contener un grupo es: 
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n= /m (1) 


Esta fórmula mantiene la privacidad total y optimiza la 
capacidad de detección de posibles manipulaciones. Como 
se muestra en la fórmula, en nuestra propuesta el número 
de nodos de la mixnet también contribuye a la precisión 
del sistema de verificación (permitiendo crear grupos más 
pequeños). No obstante, debe tenerse en cuenta que el hecho 
de añadir nodos reduce la eficiencia de la propuesta, ya que se 
incrementa el número de operaciones criptográficas a realizar 
durante los procesos de mixing y verificación. 


IV-C. Generación de pruebas de conocimiento nulo a partir 
de las Pruebas de Integridad 


La verificación de la integridad de los votos agrupados 
en cada nodo se basa en las propiedades homomórficas del 
criptosistema ElGamal: si tenemos dos votos vi y Va, una 
operación de cifrado E y dos operaciones algebraicas Q y 
9, un criptosistema con propiedades homomórficas se puede 
definir como aquél en el que E(vi) $ Elva) = Elv1 0 vz). 

Llamamos Prueba de Integridad la multiplicación de un 
grupo de votos. El resultado de multiplicar n votos de un 
mismo grupo a la entrada de un nodo de la mixnet, también 
llamada Prueba de Integridad Entrante, se puede definir como: 


n 
ITo- 
i=1 


donde r. = »);_¡7;. La multiplicación del mismo grupo 
de votos a la salida del nodo (es decir, los mismos votos 
recifrados), se llama Prueba de Integridad Saliente y es igual 


a: 


n n 


(11 LN a le == (1 v;) ] usa) 


4=1 i=1 i=1 


Te =0 [0:04] [9 =((] [90.17 gr+">> 
i=1 i=1 ¿=1 ¿=1 

Como el nodo de la mixnet conoce los factores de recifrado 
aplicados a todos los votos, éste puede calcular la suma 
del factor de recifrado de los votos de un mismo grupo 
Nr = rf. Una vez obtenido el factor de recifrado 
conjunto, el nodo puede calcular una prueba de conocimiento 
nulo de recifrado no interactiva (NIZKP-RE) para probar que 
la Prueba de Integridad Saliente es el recifrado de la Prueba 
de Integridad Entrante (del mismo grupo) usando el factor de 
recifrado r/ . Esta prueba puede basarse en el Protocolo de 
Identificación de Schnorr, com en [MA99], o en la prueba de 
Chaum-Pedersen de igualdad de logaritmos discretos [CP93]. 

De este modo, cualquier auditor puede calcular por él 
mismo las Pruebas de Integridad Entrante y Saliente de cada 
grupo de votos de un nodo y verificar la prueba NIZKP- 
RE para comprobar que las dos pruebas de integridad tienen 
los mismos contenidos. Dado que las pruebas de integridad 
están basadas en el producto homomórfico de los votos, aún 
existe la posibilidad de que un nodo malicioso pueda engañar 
al sistema. No obstante, gracias a la configuración de los 
grupos explicada en esta propuesta (ver sección IV-E1), la 
probabilidad de detección de una posible manipulación es 
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Figura 2. Verificación del proceso de mixing. 


bastante alta (por ejemplo, la probabilidad de detectar la 
manipulación de 2 votos en una elección con 10.000 votantes 
es del 99,91 %). 

Las pruebas NIZKP-RE se realizan para todos los grupos 
de votos en cada nodo. Si estas pruebas se verifican de forma 
satisfactoria, se considera que la mixnet ha realizado el proceso 
de forma correcta. 


IV-D. Resumen del protocolo de verificación 


Para resumir, el protocolo de verificación implementa los 

siguientes pasos después del proceso de mixing: 

1. Para el primer nodo de la mixnet, el verificador divide 
los votos de entrada en grupos aleatorios mediante una 
matriz de agrupamiento que envía al probador. 

2. El verificador entonces calcula una Prueba de Integridad 
Entrante para cada grupo. 

3. El verificador solicita al probador que indique la des- 
tinación de los votos pertenecientes a cada grupo en 
la salida del nodo y calcula una Prueba de Integridad 
Saliente para cada grupo. 

4. El probador calcula una prueba de conocimiento nulo 
para cada grupo basada en el factor de recifrado de 
los votos en la salida del nodo. Con ellas demuestra 
al verificador que la Prueba de Integridad Saliente de 
cada grupo es el recifrado de la Prueba de Integridad 
Entrante del mismo. 

5. En el siguiente nodo los grupos de entrada se rede- 
finen de forma que cada grupo nuevo contiene votos 
de diferentes grupos de salida del nodo anterior. Los 
pasos 2-5 se repiten hasta que se verifica el correcto 
comportamiento del último nodo de la mixnet. 


En la figura 2 se muestra un ejemplo del procedimiento de 
verificación y de la configuración de los grupos en cada nodo 
de la mixnet. 


IV-E. Propiedades del método de verificación 


IV-El. Capacidad de detección: Dado que el proceso de 
verificación se basa en Pruebas de Integridad que se calculan 
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a partir de grupos de votos, un atacante podría aprovechar 
las propiedades homomórficas del algoritmo de cifrado para 
modificar votos en la mixnet sin ser detectado: en el caso de 
que las modificaciones se cancelaran durante el cálculo de las 
Pruebas de Integridad, éstas no serían detectadas durante el 
proceso de verificación. No obstante, como la configuración 
de los grupos es desconocida hasta que el proceso de mixing 
finaliza (después de que se hayan realizado las posibles modi- 
ficaciones), la probabilidad de que un atacante modifique una 
cantidad de votos significativa sin ser detectado es negligible. 

Esta probabilidad depende de la cantidad de votos en la 
mixnet, el número de grupos en los cuales se dividen los votos, 
y el número de votos manipulados (la probabilidad de que un 
atacante no sea detectado se reduce cuando aumenta el número 
de votos modificados). La probabilidad de detectar un par de 
votos manipulados es: 

n=1 


(2) 


Psuccess = 1 -— —— 
m-=—l1 

donde m es el número total de votos y mn es el número de 
votos en cada grupo. 

El par de votos manipulados no se detectaría en caso de que 
estuvieran en el mismo grupo y el valor de las modificaciones 
se cancelara con la multiplicación para calcular la prueba 
de integridad. Por esto, es importante mantener la relación 
adecuada entre el total de votos procesados por la mixnet 
y el tamaño de los grupos: cuanto más pequeños son los 
grupos, más alta es la probabilidad de que un atacante sea 
detectado (respetando el tamaño mínimo determinado por la 
ecuación 1 para preservar la privacidad de los votantes). En 
cambio, cuanto más grandes son los grupos, más rápido es el 
proceso de verificación. 

La fórmula 1 proporciona esta relación: en una elección con 
10.000 votos y una mixnet de dos nodos, el tamaño mínimo 
de los grupos preservando la privacidad de los votantes es de 
100 votos. Con esta configuración, la detección de dos votos 
modificados es del 99 %. Si la mixnet tiene cuatro nodos, el 
tamaño mínimo de los grupos es de 10 votos y la probabilidad 
de detección aumenta al 99.91 %. 

Las probabilidades de detectar un par de votos modificados 
en una mixnet compuesta por dos nodos (grupos más grandes) 
O por cuatro nodos (grupos más pequeños) se muestran en la 
figura 3. En los dos casos la probabilidad de detección tiende 
al 100%, pero en el caso de tener más nodos esta probabilidad 
aumenta más rápidamente. 

IV-E2. Eficiencia: Preservar la privacidad de los votantes 
dividiendo los votos en grupos no solapados afecta a la 
eficiencia de la mixnet. El coste computacional del método de 
verificación depende del número de votos en el sistema y de 
la cantidad de grupos creados para el proceso de verificación, 
ya que las pruebas se realizan sobre éstos. Para un mismo 
número de votos en la mixnet, cuanto más grupos se crean 
(más pequeños) más alta es la capacidad de detección, pero 
también se consumen más recursos. 

En la figura 4 se muestra una comparación entre nuestro 
método y otros sistemas de verificación de mixnets en términos 
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Figura 3. Probabilidad de detección en mixnets de dos y cuatro nodos. 
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Figura 4. Coste de los diferentes sistemas de verificación de mixing. 


de número de exponenciaciones necesarias (ya que éstas sue- 
len ser las operaciones más costosas). Podemos comprobar que 
nuestro sistema es uno de los más rápidos cuando manejamos 
cantidades de votos razonablemente grandes. 


V. CIFRADO EFICIENTE DE LOS VOTOS 


Uno de los aspectos a tener en cuenta en la implementación 
práctica del protocolo es que los votos serán cifrados di- 
rectamente con un algoritmo de clave pública (ElGamal). 
Esto puede significar un problema desde el punto de vista 
de rendimiento para el cifrado y descifrado de votos, sobre 
todo cuando la información de éstos supera la longitud del 
bloque de cifrado. Por ejemplo, en ElGamal la información 
que se puede cifrar en un solo bloque está limitada por las 
operaciones modulares que se realizan. El límite de tamaño 
de bloque coincide con la longitud de la clave pública, que 
hoy en día se recomienda que tenga unos 2048 bits. En este 
caso concreto, esto significa que podemos incluir un voto de 
hasta unos 292 caracteres (o 2048 bits) en un solo bloque 
cifrado. El exceso de caracteres se debería cifrar en un segundo 
bloque, lo que significaría realizar un segundo cifrado y por 
lo tanto otro par de exponenciaciones (una sobre la clave 
pública y otra sobre el generador). Generalmente, para estos 
casos, se combina el cifrado simétrico con el asimétrico (1.e., 
sobres digitales), puesto que el cifrado simétrico es menos 
costoso computacionalmente que uno asimétrico. El problema 
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es que esta combinación no es compatible con las propiedades 
homomórficas ni pruebas de conocimiento nulo requeridas por 
nuestra propuesta. Por lo tanto hay que buscar alternativas 
que permitan un cifrado más eficiente del voto cuando su 
información implique más de un bloque de cifrado. 

Una opción consiste en comprimir los contenidos de los 
votos utilizando una representación de sus opciones mediante 
códigos alfanuméricos separados por caracteres especiales 
(p.e., un formato comma-separated value Oo CSV). Usando 
esta opción, se puede incluir en un único bloque cifrado un 
número mayor de opciones, pero existe una alternativa que 
además permite explotar las propiedades homomórficas del 
cifrado ElGamal. Esta consiste en representar las opciones de 
voto únicamente en un formato numérico. 

Para la representación numérica del voto, utilizaremos 
números primos (o coprimos) prefijados, como en [Pe09]. 
Usando este formato, un voto contendría el producto de 
los números primos que representan las opciones de voto 
seleccionadas. Por ejemplo, si representamos una opción de 
voto con el número 2 y otra con el número 3, un voto en el 
que se hayan seleccionado estas dos opciones se representaría 
con el número 6 (i.e., el producto de 2 y 3). De este modo, 
como los números utilizados son primos, solo haría falta una 
factorización del descifrado del voto para obtener las opciones 
individuales seleccionadas originalmente. Esta representación 
además tiene la flexibilidad de poder cifrar inicialmente de 
forma individual las opciones de voto seleccionadas y luego 
obtener el voto mediante la operación de estas opciones 
cifradas. Esto es posible gracias a la propiedad homomórfica 
multiplicativa de ElGamal. 

El cifrado individual de las opciones de voto implica a nivel 
de eficiencia un claro hándicap, pero lo consideramos porque 
es interesante desde el punto de vista de la auditoría de los 
votos, ya que permite verificar si un voto contiene opciones 
de voto válidas. Esta verificación se puede realizar mediante 
pruebas de conocimiento nulo que permitan verificar si un 
valor cifrado se encuentra dentro de un rango de valores pre- 
fijados, tal y como se explica en [CGS97]. De este modo, los 
votantes podrían enviar en lugar del voto cifrado, el conjunto 
de las opciones cifradas individualmente junto con las pruebas 
de conocimiento nulo de sus contenidos. Una vez verificado 
que los contenidos del voto son válidos, el voto se podría 
compactar mediante el producto de sus opciones cifradas. 
Esta compactación es importante para evitar problemas de 
rendimiento en la mixnet, ya que las operaciones de re-cifrado 
y las pruebas de integridad se continuarían haciendo sobre un 
único paquete cifrado (el voto compactado), en lugar de tantos 
paquetes como opciones de voto seleccionadas. 


VI. CONCLUSIONES 


En este artículo hemos presentado un sistema de verificación 
de mixnets cuyo coste computacional es cercano al de la pro- 
puesta más eficiente (ver figura 4). En términos de privacidad, 
de las propuestas más eficientes, es la única que mantiene la 
privacidad total de los votantes. Además, el método consigue 
un buen nivel de precisión, con una probabilidad de detección 


de posibles manipulaciones cercana al 100% (superior al 
99 %) cuando se procesan más de 300 votos. 

En resumen, comparada con los métodos actuales de veri- 
ficación, nuestra solución es la más equilibrada en términos 
de eficiencia, privacidad y precisión, consiguiendo además la 
propiedad de verificabilidad universal. 

Finalmente, dado que los sistemas de verificación de 
mixnets suelen requerir el uso de algoritmos de cifrado poco 
eficientes a la hora de cifrar mensajes relativamente largos 
(como ElGamal), también hemos propuesto un sistema en el 
que los votantes representan las opciones de voto en un for- 
mato numérico que aprovecha las propiedades homomórficas 
del algoritmo de cifrado para mejorar la verificabilidad del 
proceso y el rendimiento de la mixnet, así como del proceso 
de descifrado. 
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Abstract—The next generation of social networks will provide 
advanced mechanisms to look for users that are similar and 
share interests. In order to achieve this, users should be able 
to calculate their affinity using a profile that describes them. 
But these profiles will include the interests, likes and dislikes of 
the users and then store very sensitive and private data. In this 
paper, we propose a protocol that lets two users that never met 
in advance to compare their profiles and check whether or not 
they are affine, without leaking any private information in case 
of mismatch. The protocol that we propose is based on the well 
known graph and subgraph isomorphism problems. 


Index Terms—social networks, profiling, privacy, security, 
graph isomorphism, subgraph isomorphism. 


I. ESCENARIO Y OBJETIVOS 


En las redes sociales los usuarios publican sus puntos de 
vista, intereses y aficiones. Uno de los servicios que las redes 
sociales ofrecerán en un futuro inmediato es la búsqueda de 
personas que tengan intereses similares, con el objetivo de que 
se enlacen entre ellos y así se mejore el funcionamiento de la 
red. Pero para ello los usuarios deben publicar su perfil de 
forma que todo el mundo pueda compararse con él, lo que 
supone mostrar una gran cantidad de información personal 
que no todos los usuarios estarán dispuestos a publicar. Para 
proteger a estos usuarios, en este artículo proponemos un 
protocolo que compare a dos personas sin que sea necesario 
publicar ningún tipo de información privada, incluyendo sus 
intereses. 


A. Modelo social 


En la red social estudiada, dos usuarios con perfiles simi- 
lares querrán enlazarse entre sí porque cada uno de ellos tendrá 
documentos que pueden ser de interés al otro. Así, los perfiles 
de un usuario de deben crear a partir de los perfiles de los 
documentos que comparte dentro de la red. A continuación 
veremos cómo es posible. 

En una red P2P hay un conjunto de documentos únicos 
R = ([r1,12,...,'m). Estos documentos o recursos pueden 
describirse con meta-datos, campos e inspección interna de 
forma que es posible definir conjuntos de palabras, bag-of- 
words [1]. De acuerdo con [2], es posible definir una ontología 
de clasificación de los recursos en R. Esto es, se obtienen 
n categorías semánticas con las que podemos describir los 
recursos en R. Así, cada recurso r; € R tiene asociado un 
perfil dentro de esa ontología p(r;) = (c1,C2,...,Cn). En 
este trabajo supondremos que los componentes c, de p(r) son 


números reales entre O y 1 y que cada uno de las categorías 
es independiente de las demás. Llamamos espacio social 
P = [0,1]” al conjunto de todos los perfiles posibles. Sobre 
este conjunto definimos una función distancia d : Px P > R. 
A partir de los perfiles de los documentos que un usuario 
comparte es posible crear un perfil de usuario. Un ejemplo 
trivial es asociar como perfil de un usuario la media de los 
perfiles de los documentos que comparte dentro de la red. 
Otra posibilidad más compleja es que se tenga en cuenta el 
comportamiento pasado del usuario así como la descripción 
que haga él mismo de sus intereses a la hora de calcular el 
perfil de un usuario. Sea como sea, asumimos que los perfiles 
de usuario también pertenecerán al espacio social [P. Así, dado 
un número real A € R, decimos que dos usuarios a y b son 
afines si y solo si sus perfiles asociados verifican d(A, B) < A. 
En este trabajo no hacemos ninguna suposición sobre cómo 
los perfiles en P son asignados a cada documento, ni hacemos 
ninguna asunción sobre la distancia particular usada en d. 
Pero aunque en este trabajo estemos usando perfiles abstractos, 
creemos que en un entorno real que dos perfiles sean afines 
captura la similitud entre usuarios de una red social. En este 
sentido, si dos usuarios son afines, entonces sus gustos son 
similares y probablemente estos dos usuarios querrán cono- 
cerse, conectarse o compartir conocimientos y documentos. 


B. Modelo de seguridad 


En este trabajo asumimos que los usuarios no están or- 
ganizados de ninguna manera ni se conocen de antemano. 
Además, no existe un servidor central que pueda manejar la 
confianza entre los usuarios, ni autentificar las identidades de 
los mismos. Es decir, no es posible para un usuario comprobar 
si el perfil presentado por otro usuario que resulta ser afín 
no es falso. Esto es, un usuario malicioso podría falsear su 
perfil o incluso auto-asignarse cualquier perfil posible dentro 
de [P, e incluso cambiar su perfil de forma dinámica y aparecer 
con diferentes identidades. Finalmente, no exigiremos que 
existan canales seguros entre los nodos de la red, así que 
la comunicación entre dos usuarios puede ser perfectamente 
conocida por un usuario malicioso que la está interviniendo, 
ya sea pasivamente o como man-in-the-middle. 

Los atacantes de este sistema son de dos tipos. El primero 
de ellos es un observador de la comunicación pasivo que 
no participa en el protocolo pero que tiene la posibilidad de 
obtener y analizar todos los mensajes intercambiados por Alice 
y Bob. Este atacante gana si es capaz de obtener cualquier 
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información de cualquiera de los perfiles de Alice (4) o Bob 
(Bb). Este requisito se verifica no solo si el atacante es capaz 
de descubrir A ó B, ya sea completos o parcialmente, sino 
también se verificará si es capaz de descubrir la afinidad 
d(A, B) o incluso si es verdad que d(A, B) < A!. 

El siguiente tipo de atacante es un usuario activo Malloy 
que corre el protocolo con cualquier perfil M que le pueda 
interesar ejecutar. Fácilmente se comprueba que si Malloy se 
asigna a sí mismo un perfil afín con Alice, entonces Malloy 
conoce que A está dentro de la hiperesfera centrada en M y 
de radio A. Si este radio es muy pequeño, conocerá el perfil de 
Alice con muy poco error. El objetivo de este trabajo es que 
la probabilidad de que Malloy se asigne un perfil a sí mismo 
que sea afín con Alice no es mayor que la simple suerte, con 
lo que el ataque se vería reducido a una forma de ataque por 
fuerza bruta. Además, si el perfil M no es afín, Malloy no 
debería obtener mayor información sobre la distancia que le 
separa realmente de Alice, de forma que no sea posible ningún 
tipo de ataque por triangulación de perfiles. 


C. Objetivo 


Dos usuarios diferentes, Alice y Bob, se encuentran en una 
red social por primera vez. Quieren conocer si es verdad o no 
que son afines. Formalmente, si A es el perfil de Alice y B 
es el perfil de Bob, quieren conocer si es cierto o no que la 
distancia entre ambos es menor que A, para un cierto valor 
A ER que se ha acordado previamente: 


1: (d(4,B)<A) (1) 


La salida de (1) es 1 si se verifica la desigualdad, o 0 si no lo 
hace. Alice y Bob no desean que la otra parte gane ningún tipo 
de conocimiento aparte del resultado de la comparación. Es 
decir, no solo el perfil real de cada uno de ellos sino también 
la distancia que los separa debe ser mantenida en secreto. 

En este trabajo definiremos un protocolo que permita a dos 
usuarios Alice y Bob validar si son afines para un cierto A 
sin dar más información que la salida de (1). Este protocolo 
estará basado en los problemas del isomorfismo de grafos y 
subgrafos. 


D. Una vista más amplia: caso de uso 


Pretendemos utilizar el protocolo que describiremos en este 
trabajo de la siguiente forma. En una red social los usuarios se 
encuentran con otros muchos usuarios. Queremos diseñar un 
sistema que permita enlazar a los usuarios de la red social 
que compartan intereses comunes. De esta manera, podrán 
fraternizar, compartir, o realizarse recomendaciones unos a 
los otros sobre documentos que cada uno de ellos posea. 
Si un usuario se enlaza con otros usuarios con sus mismos 
intereses dentro de la red social, entonces los documentos de 


Al menos, durante la ejecución del protocolo. Si Alice y Bob continúan 
comunicándose con posterioridad, entonces un atacante podría inferir que es 
muy probable tanga perfiles afines. Protegerse de este ataque está fuera de 
los objetivos de este trabajo, aunque podría solucionarse si se exige que las 
comunicaciones siguientes entre Alice y Bob se realicen a través de sistemas 
que garanticen el anonimato como [3] 


estos usuarios probablemente también sean de interés para el 
primero de ellos. 

Pero los usuarios maliciosos están por todas partes. Redes 
como Facebook o LinkedIn ganan dinero con la información 
privada de los usuarios. Google guarda información personal 
sobre sus usuarios que permite la creación de perfiles enorme- 
mente detallados. Empresas de espionaje industrial, personal, 
comerciales, otro usuarios particulares o gobiernos podrían 
utilizar la información personal de los usuarios en su contra. 

Para resolver estos ataques a la privacidad de un usuario 
de redes sociales, apostamos por la creación de una red 
descentralizada donde los usuarios puedan conocer a otros con 
sus mismos intereses sin necesidad de enviar sus perfiles a un 
servidor central controlado externamente, ni que otros usuarios 
maliciosos puedan recoger una gran cantidad de perfiles de los 
demás usuarios de la red. 


TI. TRABAJO RELACIONADO 


A. Computación multiparte segura 


Hay varias propuestas en la literatura que intentan resolver 
un problema similar mediante la utilización de computación 
multiparte segura. En teoría, si cada una de las partes corre 
un protocolo de computación multiparte usando su propio 
perfil como entrada, podría calcularse la distancia entre ambos 
perfiles sin necesidad de que los mismos se intercambien. 
Incluso es posible definir una función que no calcule la 
distancia, sino que resuelva directamente (1). [4] describe 
una puerta condicional que es capaz de resolver operaciones 
complejas en computación multiparte. Uno de los ejemplos 
de aplicación es precisamente la resolución de una función 
muy similar a (1). Pero los autores limitan la definición de 
intereses a un número binario 0— 1, y la métrica a la distancia 
de Hamming entre los perfiles. Intentar aplicar esta misma 
solución al entorno más complejo descrito en la sección I-D, 
con vectores de centenares de categorías cada una cuantificada 
en 8 bits, llevaría a un número necesario de mensajes que los 
usuarios tienen que intercambiar totalmente inaceptable. Los 
autores pensamos que el número de interacciones necesarias 
si se utilizan sistemas de computación multiparte limita seria- 
mente su aplicación para el cálculo de afinidad entre perfiles 
a escenarios muy particulares y simplificados. 

El problema del isomorfismo de grafos se ha utilizado en 
ocasiones en la literatura de seguridad. [5] presenta un pro- 
tocolo zero-knowledge genérico que puede utilizar cualquier 
problema NP-Complete para autentificar a un usuario, y dos de 
los ejemplos explícitamente incluidos son el problema de iso- 
morfismo de grafos y subgrafos. Aunque el protocolo genérico 
no es directamente aplicable en nuestro escenario, lo hemos 
utilizado como inspiración de nuestro trabajo. Por otro lado, 
[5] no toma en cuenta las aproximaciones a la solución del 
problema de isomorfismo, que analizaremos en la sección V. 
[6] describe un protocolo para realizar autenticación mutua 
entre cliente y punto de acceso a una red WiFi aprovechando la 
complejidad del problema de isomorfismo de grafos. De nuevo 
el protocolo presentado allí no es de aplicación en nuestro 
escenario de perfiles sociales. 
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B. Teoría de grafos 


Un grafo es un par G = (V, L) formado por un conjunto 
de vértices Y = ([v,,vz,..., Up y un conjunto de enlaces 
entre ellos L = ¿((v;,v;), (uz, Ux), .... En este trabajo solo 
consideraremos grafos simétricos, es decir, los enlaces en L 
no tienen dirección y no hay enlaces en bucle que empiecen y 
acaben en el mismo nodo. Un subgrafo G, = (Vs, L,) de G 
es un grafo tal que V, CV y L, = LN(V, x V,). Es decir, el 
subgrafo está formado por un subconjunto de vértices del grafo 
original y todos los enlaces que unen a este subconjunto de 
vértices del grafo original. Dos grafos G y H son isomórficos 
si y solo si comparten el mismo conjunto de vértices V y 
existe una permutación rr : (1,2,...,n > (1,2,...,n) tal 
que V ¿,j(v;,vj) € La + (Uri), Ur(y)) € Lu. Es decir, si 
podemos reetiquetar los vértices de G de forma que tengamos 
el grafo H. En este caso, escribimos H = TG. 

En teoría de la complejidad, se dice que un problema 
pertenece al conjunto NP si existe una máquina de Turing no 
determinista (NDTM) que pueda resolver el problema en un 
tiempo polinomial. Una definición ligeramente diferente pero 
equivalente es que VP alberga la clase de problemas en las 
cuales una solución puede probarse en un tiempo polinomial 
por una máquina de Turing determinista (DTM). Un subcon- 
junto interesante de NP es el conjunto NP — Complete. 
Un problema p es NP — Complete si es NP y cualquier 
otro problema NP puede ser convertido en p en un tiempo 
polinomial. Actualmente, los problemas en NP — Complete 
se consideran intratables, ya que no hay ningún algoritmo 
conocido para una máquina DTM que pueda resolver un 
problema NP — Complete en un tiempo polinomial. En lo 
que nos interesa, el problema de comprobar si es verdad o 
no que un grafo G es isomórfico con un subgrafo de H es 
un problema NP — Complete, mientras que el problema de 
comprobar si dos grafos G y H son isomorfos es un problema 
NP (pero no se sabe si NP — Complete ó P). 


III. DESCRIPCIÓN DEL PROTOCOLO 


A continuación detallamos el protocolo propuesto para 
alcanzar los objetivos de la sección 1-C. Dados dos usuarios, 
a y b, con perfiles A y B, se ponen de acuerdo en los 
números reales y y A. A será el utilizado para comprobar si se 
verifica (1), mientras que estudiaremos las restricciones sobre 
“y en la sección MI-A. Ambos usuarios ejecutan el siguiente 
protocolo. 


1) Ambos usuarios a y b se ponen de acuerdo en un grafo 
G = (V, E), construido de tal manera que: 1. todos sus 
vértices V = ([v1,uz,..., US) están separados al menos 
una distancia y; 2. los enlaces en L son aleatorios. G es 
la entrada común al protocolo, y es conocido por ambos 
usuarios. El número de vértices en G se representará 
como g. Vea la sección V para requisitos adicionales 
para este grafo. 

2) A cada punto del espacio social [P se le asigna el vértice 
de V que esté más cercano. Es decir, se define una 
función de clusterización c : P > V de tal forma que el 
vértice v, asignado a un punto p del espacio sea el que 
minimice d(v,,p). 


3) Ambos usuarios a y b se ponen de acuerdo en un número 
real y > y. 

4) De forma secreta, el usuario, x € fa,bj calcula los 
conjuntos HS(X,A) y HS(X,2A), siendo el conjunto 
HS(P,r) = [Z € Pld(P,Z2) < rj. Es decir, la 
hiperesfera HS(A,A) es el conjunto de perfiles de P 
que están dentro de un radio de A unidades del perfil A. 

5) De forma secreta, el usuario x calcula los conjuntos 
Cos y C?, ambos subconjuntos de V. El subconjunto 
de vértices c(HS(P,r)) € V está formando por los 
vértices de Y asignados a los puntos de la hiperesfera 
HS(P,r) a través de la función c. Abusando de la 
notación, escribiremos C, = c(HS(X,A)) y C? = 
cd HS(X,2A)). 

6) Cada usuario calcula los grafos H., y H2 como los 
subgrafos de G derivados de los subconjuntos de vértices 
Ca y de extendidos a una distancia y. Esto es, A, in- 
cluye los vértices C., y todos aquellos vértices de V que 
estén a una distancia menor que y de cualquier vértice 
de C... H? se construye de forma similar, utilizando C? 
como conjunto de vértices base. 

7) Cada usuario x= escoge un isomorfismo cualquiera q. : 
V > V, y envía al otro participante H.(H.) y d+ (H?). 

8) Si cualquiera de los pares ($, (Hy), Ha), (9y(H¿), Hz) 
6 ($, (H,), H?) es isomorfo, cada usuario acepta indi- 
vidualmente que d(A, B) < A. 


Análisis: El núcleo de este protocolo es que el único dato 
que se intercambian los usuarios son los grafos dH.«(H.) y 
d+ (H?). Estos conjuntos se crean a través de isomorfismos 
sobre los subgrafos de G formado con los vértices cuyos 
perfiles asociados son los más cercanos al perfil de x. Si un 
atacante obtiene el grafo /..(H.,) y es capaz de deshacer el 
isomorfismo, entonces será capaz de obtener este subgrafo 
original y podrá hacer una estimación bastante aproximada 
del perfil del usuario. Pero para ello tendría que resolver 
el problema del isomorfismo de subgrafos, que como se ha 
discutido en la sección II-B, es un problema N P— Complete 
y actualmente considerado intratable. Aún así, dos usuarios 
legítimos tendrán que resolver el problema del isomorfismo de 
grafos en el último paso del protocolo. Este es un problema 
NP, pero no se sabe si es NP — Complete. En la sección V 
se discutirá sobre la viabilidad computacional de los usuarios 
para resolver este problema. En nuestro caso, el parámetro 
p sirve para modular el número de vértices que tendrá el 
grafo Pz(H.,) final, llevando el escenario a la zona donde el 
problema de isomorfismo de grafos es resoluble, pero no lo 
es el problema del isomorfismo de subgrafos. 


A. Límites para el parámetro “y 


A continuación estudiaremos los conjuntos C. y C?. La 
idea sobre la que soportamos nuestro protocolo es que dos 
usuarios cuyos perfiles verifiquen (1) deberían tener alguno de 
estos conjuntos iguales. Como veremos, la creación de estos 
conjuntos nos limitará los posibles valores del parámetro y. 
Estudiaremos varios casos de intersecciones entre las hiperes- 
feras HS y los clusters creados por la función c: 
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(b) Borde del clúster 
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(a) Centro del clúster 
Figure 1. Los tres escenarios analizados de cortes de clusters e hiperesferas 


a) Zona central de los clusters: Si una hiperesfera 
HS(p, A) es mayor que un clúster, entonces ésta siempre 
contendrá más de un clúster y la comparación de C(p, A) 
y C(q,A) pierde sentido en el caso general. Para evitarlo, 
se exigirá que la distancia mínima entre dos vértices de G 
sea Ymin = 24. En este caso una hiperesfera perfectamente 
centrada en el clúster no cortará a ningún clúster más, y por 
tanto es posible comparar los conjuntos C¿ de dos usuarios. 
Por otro lado, si y > 22, entonces un solo clúster podría 
albergar dentro de sí mismo varias hiperesferas que tengan 
perfiles más lejanos que A, como se muestra en la figura 1(a), 
resultando en un aumento de los falsos positivos. Así, conviene 
acotar UN Ya, para reducir el número de falsos positivos. 


b) Bordes: En los bordes de los clusters puede darse el 
caso de que una hiperesfera centrada en p esté contenida en un 
solo clúster mientras que otra centrada en q tal que d(p, q) <A 
corte a dos o más clusters adicionales. En este escenario, 
simplemente comparar los dos conjuntos de clusters llevaría a 
un falso negativo. Por tanto, se ha introducido en el protocolo 
un nuevo conjunto de clusters C?, los cortados por una 
hiperesfera centrada en p y con radio 24. Efectivamente, esta 
hiperesfera contiene a H.S(q, A) y por tanto todos los clusters 
cortados por H.S(q, A) también serán cortados por HS(p, 24). 
Este es el motivo por el que el protocolo comprueba durante 
la fase 8 no solo el corte de las hiperesferas de radio A, sino 
también el corte de las hiperesferas de radio una A y otra 21. 
El lector podrá comprobar que no se gana nada comparando 
los cortes de las hiperesferas 2A, ya que sería exactamente 
el mismo caso con los mismos errores que comparar las 
hiperesferas con radios A. Con esta modificación, el protocolo 
resultará positivo si cualquiera de estos conjuntos de clusters 
comparados son iguales. De igual forma y como muestra la 
figura 1(b), para que dos hiperesferas de radio 2A no corten 
clusters diferentes, es necesario que y > 4A para que dos 
bordes estén separados al menos la distancia equivalente a un 
diámetro de la hiperesfera. 


c) Esquinas: Es un hecho conocido que las únicas figuras 
que mantienen una distancia fija llamada diámetro entre dos 
puntos de sus bordes son el triángulo equilátero en espacios 
bidimensionales y las hiperesferas en cualquier dimensión. 


(c) Esquinas del clúster 


Además, no es posible hacer una partición del espacio solo 
con hiperesferas. De esta forma, la implicación descrita en 
el párrafo anterior solo funciona en un sentido y aunque los 
clusters cubiertos por la hiperesfera H.S(q, A) también estén 
cubiertos por la hiperesfera HS(p,2A), esta última también 
puede cubrir nuevos clusters. En este caso, los conjuntos de 
clusters C., y C? son diferentes, y por tanto el protocolo dará 
un falso negativo. Llamamos “esquinas” a las zonas del clúster 
donde no es posible mantener la restricción sobre y, como 
muestra la figura 1(c). No hemos sido capaces de encontrar 
una solución sencilla a este problema sin añadir complejidad 
adicional al protocolo, aunque se puede minimizar su efecto 
sobre los falsos negativos maximizando el valor de y. En la 
sección de simulación estudiaremos hasta qué punto influye 
en los resultados obtenidos. 


B. Límites en el valor A 


Para esta sección utilizaremos la métrica euclídea para 
calcular distancias entre perfiles de usuario. Aunque los re- 
sultados numéricos no coincidan si utilizamos otras métricas, 
los resultados cualitativos sí que lo harán. 

Si asumimos que los usuarios se extienden uniformemente 
en el espacio social, el perfil medio que podemos encontrar es 
p= (3, 3, De 5), y en este caso, la distancia media máxima 
a cualquier otro perfil en P es: 


dae = S 


Según los límites encontrados en la sección anterior para 
los elementos de G, la distancia máxima entre dos perfiles 
cualesquiera 9; y g¿ de G €S Ymax = 44, así que: 


1 


yA 
2 2 


(2) 


dA< d(g, 9) < deis = 
yn 


3 (4) 


La ecuación (4) da un valor máximo para el umbral que se 
puede utilizar en una dimensión n para comparar perfiles. Con 
valores de Á por encima de este valor máximo, no será posible 


2 (3) 


A< 
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crear los parámetros necesarios para correr el protocolo. Por 
ejemplo, en una red social donde se definen perfiles con n = 
200 categorías, el valor umbral máximo que pueden usar los 
usuarios para compararse con este protocolo es A = 1,178. 


IV. SIMULACIÓN DEL PROTOCOLO 


En esta sección simularemos el protocolo que ha sido 
definido en este documento. Para ello definiremos un espacio 
social de n = 20 categorías. Utilizaremos y = 0.1 y 
definiremos un grafo G con los vértices en cada uno de los 
puntos separados y en cada dirección. Para simplificar las 
simulaciones pero sin pérdida de generalidad, ya que solo 
pretendemos comprobar la validez del protocolo, definiremos 
los clusters como los hipercubos centrados en cada uno de 
los vértices de G de arista y. Finalmente, para comprobar la 
validez del protocolo bastará con comprobar si coinciden los 
conjuntos C Ó C? de cada usuario. 

En la figura 2(a) se muestra la relación de falsos negativos 
con respecto a los positivos, y de falsos positivos con respecto 
a los negativos para varios valores de y/A. Del apartado 
anterior concluimos que y > 4A y a la vez tan pequeño 
como sea posible. Por inspección de la figura 2(a), un valor de 
“y = 64 consigue un ratio de falsos negativos cercano al 20%, y 
este ratio disminuye exponencialmente con la relación y/A. A 
la vez, el ratio de falsos positivos con respecto a los negativos 
aumenta lentamente con la relación y/A, siendo cercano al 
40% para el valor y = 61. 

Pero más importante aún es la comparación de la figura 2(b). 
Esta figura muestra la media de distancias efectiva de los 
perfiles que el protocolo considera como positivos con respecto 
al umbral A. Es decir, un valor de este parámetro de 2 
significa que el protocolo considera positivos los perfiles con 
distancia media 24. Como se comprueba en la figura, las 
simulaciones muestran que esta distancia efectiva aumenta de 
forma aproximadamente lineal a medida que aumenta el ratio 
y/A. Así, queda justificado el análisis de la sección anterior, 
recomendando un valor de y tan pequeño como sea posible. 
Para y = 4A, que cumple los requisitos del protocolo, la 
distancia efectiva de los perfiles positivos es 24. Aunque este 
valor de falsos positivos puede parecer alto, el lector recordará 
que estos falsos positivos se darán entre aquellos perfiles que 
compartan clúster con el perfil de ensayo. Esto es, la distancia 
máxima entre el perfil a considerar y cualquiera de los falsos 
positivos tendrá que ser menor que y. Así, el protocolo en 
realidad es capaz de comparar perfiles no con el umbral A, 
sino con un umbral A” intermedio entre A y y = 4). 

Finalmente, el caso de uso propuesto en la sección I-D se 
ha estudiado en otros trabajos como [7]. En el algoritmo de 
enrutamiento allí, los falsos positivos ayudan en la creación 
de grupos de afinidades entre usuarios. En ese caso, un falso 
positivo que además tiene la distancia máxima limitada con y 
no solo no es un inconveniente para el sistema, sino que es 
una ayuda para el mismo. 


V. DISCUSIÓN: VIABILIDAD COMPUTACIONAL 


El reconocimiento de formas en grafos es un campo con 
30 años de investigación ininterrumpida. Aunque el problema 


de isomorfismo de subgrafos sea NP — Complete y no se 
conozca la clasificación final del problema de isomorfismo 
de grafos, se han presentado algoritmos capaces de resolver 
en algunos casos ambos problemas en un tiempo razonable. 
De hecho, para que nuestra propuesta sea viable es necesario 
que se cumplan dos condiciones: 1.- que dos usuarios puedan 
decidir rápidamente si los grafos finales resultantes de la 
ejecución del protocolo son isomorfos 2.- que dado uno de 
estos grafos, no se pueda encontrar a qué parte del grafo 
original G corresponde. La primera condición supone que los 
grafos finales tienen que ser tales que el problema de decisión 
de isomorfismo de grafos sea tratable, mientras que la segunda 
exige que el problema de búsqueda derivado del problema de 
decisión de isomorfismo de subgrafos no sea computable. 

En [8] se presenta un algoritmo para la resolución de 
ambos problemas. Los autores defienden que su propuesta 
tiene complejidad temporal O(V?) en el mejor de los casos, y 
O(NIN) en el peor, siendo N el número de nodos en el grafo. 
Además, presentan resultados de la ejecución del algoritmo 
para el reconocimiento de grafos isomorfos, pudiendo resolver 
el problema para N = 1000 nodos en tiempos cercanos 
al segundo. Además, en este mismo trabajo se presentan 
los resultados obtenidos con otros algoritmos clásicos, que 
obtienen una complejidad temporal similar en algunos casos. 
Así, podemos concluir que para grafos con un número de 
vértices cercano a 1000 el problema del isomorfismo de grafos 
es resoluble en un tiempo perfectamente razonable, y podemos 
asumir que el primer requisito de nuestra propuesta se puede 
alcanzar si exigimos que los grafos C y C? tienen un número 
de nodos como máximo de 1000 nodos. 

Analizaremos a continuación la viabilidad del segundo 
requisito, que el problema del isomorfismo de subgrafos no 
sea resoluble y por tanto un atacante no pueda identificar un 
subgrafo de G que sea isomorfo con C,, porque en ese caso 
conocería los nodos de G afines a a. Como se describió en la 
sección I-D, queremos aplicar este protocolo en un sistema 
de recomendación. Para que el sistema de recomendación 
sea útil se debe utilizar un número alto de categorías. Con- 
sideramos, así, usuarios que muestran su interés en cientos 
de categorías diferentes y hemos trabajado en espacios de 
200 categorías. En este caso, incluso suponiendo un 
valor alto para la distancia mínima entre perfiles dentro de 
G como y = 0.2, el número de posibles vértices dentro 
de G es enorme, Ninas = 1” = 52%, Un número tan 
grande no puede ser tratado en un tiempo razonable por los 
algoritmos clásicos ni por las nuevas propuestas como [8], 
así que podemos considerar que en el caso general de G 
y para nuestro escenario, los dos requisitos de viabilidad 
computacional se verifican. 

Pero existe una línea de ataque descrita en la literatura 
actual de privacidad que podría aplicarse en este caso. Si el 
atacante es capaz de introducir dentro de G un subgrafo H 
que cumpla ciertas características, la resolución del problema 
puede simplificarse. Por ejemplo, en [9] se presenta un método 
para introducir un pequeño grafo H dentro de otro mucho 
mayor G, y que pueda identificarse después de isomorfismos. 
Si un atacante puede introducir estos subgrafos durante la 
creación de G, podría de forma efectiva controlar varias zonas 
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(a) Falsos positivos y negativos en relación a y/A 


Figure 2. Resultados de la simulación para y = 0,1, n= 100 


del espacio social. Como los autores demuestran en su trabajo, 
para que este ataque tenga éxito, el grafo H introducido 
por el atacante tiene que tener como máximo del orden de 
O(log(N)) nodos, y cada nodo del orden de O(log(W)) 
vecinos. Los autores son capaces de recoger información con 
un subgrafo tan pequeño como 7 nodos introducido en una red 
social de 4 millones de nodos. Estos subgrafos H no tienen 
ninguna característica especial que permita a personas difer- 
entes al atacante identificarlos, con lo que pueden permanecer 
perfectamente ocultos dentro de G. 

Para resolver este problema proponemos que la creación 
de G sea controlada por ambas partes. Si G se crea 
dinámicamente en el momento de la comparación, se debe 
utilizar un algoritmo que impida la introducción de los grafos 
H arbitrarios. Por ejemplo, si ambas partes acuerdan un 
algoritmo de generación de números aleatorios y una semilla, 
y utilizan este algoritmo para la creación de enlaces aleatorios 
dentro de G, no es posible inyectar grafos H en G. Otra 
opción es que ambas partes se aseguren de que el grafo G 
verifica la propiedad de “k-anonimato de vecinos”, es decir, 
que dado cualquier nodo y su vecindario, se puedan encontrar 
k vértices en la red cuyo vecindario es isomorfo al nodo que 
estamos testeando. En [10] puede encontrarse un algoritmo de 
generación de un grafo G que cumple esta propiedad. 


VI. CONCLUSIONES Y LÍNEAS FUTURAS 


En este documento hemos desarrollado un protocolo para el 
cálculo de afinidades entre dos usuarios sin que cada uno de 
ellos aprenda más información sobre el otro que la afinidad. La 
base del protocolo es el problema de isomorfismo de grafos, 
que se considera en la actualidad no tratable en general aunque 
se hayan hecho aproximaciones en su solución. 

Mediante simulaciones constatamos que el protocolo tiene 
un éxito parcial, y aunque es posible limitar el número de 
falsos negativos tanto como sea necesario, el número de falsos 
positivos es creciente con y. Aún así, ya que conviene tener 
un y lo más pequeño posible y en cualquier caso los perfiles 
positivos tendrán una distancia menor que y entre sí, las 
consecuencias de los falsos positivos son limitadas. 

Para comprobar las características estadísticas del proto- 
colo hemos realizado algunas simulaciones en un escenario 
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(b) Distancias efectivas que el protocolo identifica como afines 


simplificado. En particular, hemos considerado particiones 
del espacio social como hipercubos. Existen particiones más 
óptimas que no se han considerado, y creemos que es posible 
definir dinámicamente el grafo G de forma que minimice los 
falsos positivos. Estas son líneas abiertas de investigación para 
trabajos futuros. 
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Resumen—En este trabajo, presentamos una propuesta para 
la realización de procesos automáticos de negociación en entornos 
móviles a través del despliegue de políticas condicionadas. Dichas 
políticas contienen un conjunto de atributos, condicionados por 
el nivel de confianza en el proceso de negociación, para proteger 
aquellas informaciones consideradas como sensibles o que poten- 
cialmente pudieran violar su privacidad. A medida que avance 
el proceso de negociación, los atributos servirán de mecanismo 
de control para concluir las distintas etapas que componen el 
proceso. Presentamos una visión práctica de nuestra estrategia 
orientada hacia su integración en aplicaciones pervasivas de 
comercio electrónico basadas en el uso de agentes móviles y 
políticas definidas según el estándar XACML. 


I. INTRODUCCIÓN 


Dadas las tendencias actuales en entornos de usuario de 
aplicaciones móviles y/o pervasivas, aparece con frecuencia 
un requisito básico: un proceso de negociación automático. 
El objetivo suele ser, por lo general, cubrir las necesidades 
de optimización de parámetros de dichos entornos. Algunos 
ejemplos apropiados podrían ser la optimización de parámetros 
en escenarios de tipo roaming (para conseguir los mejores 
parámetros de calidad de servicio) o multi-homing (para con- 
seguir accesos de tipo always best connected). Por supuesto, es 
importante destacar también la necesidad de negociación con 
simples propósitos transaccionales (por ejemplo, búsqueda de 
una oferta, no necesariamente la más barata, en escenarios 
tradicionales de tipo proveedor-consumidor). 

Todos estos procesos de negociación suelen requerir el inter- 
cambio de datos de carácter personal (tales como, preferencias 
de usuario, datos bancarios o histórico de negociaciones pre- 
vias). Parte de esta información es generalmente vista por el 
usuario como sensible o privada. De hecho, este tipo de datos 
puede ser utilizado por los proveedores de manera inapropiada 
(por ejemplo, utilización ilícita de métodos de profiling para 
garantizar QoS). La necesidad de garantizar una protección 
adecuada de dichos datos se pone de manifiesto de manera aún 
más acentuada cuando el proceso de negociación se ejecuta, 
en nombre del usuario, por entidades software autónomas. 

Estas entidades suelen ejecutar el proceso de negociación en 
plataformas distantes, diseminando registros sobre el usuario. 
Estos registros pueden ser utilizados por un adversario para 
violar su privacidad. Así, por ejemplo, trabajos como [7] han 


mostrado que tan sólo un mínimo de conocimiento sobre un 
individuo, cuya identidad se ha borrado de un proveedor de 
servicios, puede ser suficiente para identificarlo a partir de un 
conjunto de datos públicos. Es necesario, pues, introducir un 
mecanismo de protección adicional en estos entornos. 

En este trabajo proponemos un mecanismo sencillo, a la 
vez que eficiente, para permitir la revelación progresiva de 
información de carácter personal en entornos pervasivos de 
negociación automática. Para ello, nos centramos en la realiza- 
ción del proceso por parte de agentes móviles. Estos presentan 
dos características importantes, movilidad efectiva de código 
(con todo lo que ello comporta), y capacidad de negociación en 
nombre del usuario. Así mismo, planteamos un acercamiento 
a la negociación basado en políticas, de manera similar a [9], 
[51, [1], donde agentes móviles se utilizan para automatizar la 
negociación entre clientes y proveedores de servicios. Nuestra 
propuesta se puede ver como una simplificación de sistemas de 
trust negotiation [8], [13], o como un soporte complementario 
a estas en entornos de computación móvil en general. 


Organización del artículo — El resto del artículo se ha 
organizado de la siguiente manera: La sección II presenta 
algunos antecedentes en relación a nuestra propuesta. La 
sección III define de manera más concreta la motivación de 
nuestro trabajo y presenta la propuesta haciendo hincapié 
en su arquitectura y aportando notas de implementación. 
Finalmente, la sección IV concluye el artículo. 


TI. ANTECEDENTES 


Multitud de técnicas de negociación han sido propuestas y 
analizadas en el área de la matemática aplicada y de la teoría 
de juegos [4], [10]. La mayoría de estas técnicas tratan de 
utilizar modelos formales para definir e interpretar interaccio- 
nes entre dos o más participantes, en forma de incentivos que 
conducirán finalmente el proceso de decisión de cada partici- 
pante. Podemos encontrar, entre dichas soluciones, el estudio 
de estrategias que garanticen una decisión Óptima, en términos 
económicos, a través de la detección de comportamientos 
preestablecidos. Estas técnicas han influenciado de manera 
decisiva la mayoría de soluciones basadas en la utilización de 
agentes y/o técnicas de computación cooperativa. De hecho, 
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estas soluciones han sido adaptadas con éxito hacia marcos de 
trabajo específicos en el área de negociación en aplicaciones 
de comercio electrónico [9] y redes IP móviles [5], [1]. La 
utilización de estas técnicas de negociación se prevé de vital 
importancia para las futuras aplicaciones de la tecnología 
ubicua, siendo de especial relevancia la necesidad de procesos 
de negociación que garanticen un intercambio mínimo de datos 
de carácter personal entre consumidores y proveedores de 
servicios electrónicos [12]. 


Cualquier proceso de negociación requiere la realización de 
una toma de decisiones. Estas decisiones son influenciadas, 
en gran medida, por las necesidades propias de cada una 
de las partes involucradas en el proceso. La capacidad de 
anticiparse a los deseos o motivaciones de un participante 
puede suponer una clara ventaja para sus oponentes. Por este 
motivo, la mayoría de sistemas de apoyo a la negociación 
tratan de anticiparse a los deseos/necesidades de sus oponentes 
mediante la incorporación de métodos que permitan modelar, y 
por lo tanto, anticipar, las decisiones de los participantes [11]. 
Asumamos, por ejemplo, aplicaciones de negociación electró- 
nica de tipo policy-driven. Estas aplicaciones acostumbran a 
conducir el proceso de negociación a partir del intercambio 
de un conjunto de políticas en formato electrónico. Estas 
políticas permiten definir, a partir de lenguajes formales ba- 
sados en lógica de primer orden, por ejemplo, el conjunto de 
declaraciones que será utilizado en el proceso de negociación. 
Multitud de lenguajes han sido propuestos en la literatura con 
el objetivo de formalizar este proceso [2]. Existen también en 
la literatura métodos de detección que permiten el análisis de 


<Transaction name="SubmitProposal" ... > 
<Collaboration name="ReachAgreement"> 
< InitiatingRole name="Requester" id="... /> 
<RespondingRole name="Responder" id="... /> 
<Activity name="RequesterNegotiation" 
binaryCollaboration="ConductNegotiation" 
fromAuthorizedRole="AgreementRequester" 
toAuthorizedRole="AgreementResponder"> 
<Start toState="RequesterNegotiation” ... /> 
<Transition fromState="RequesterNegotiation" 
toState="RequesterContract" 
conditionGuard="Success" 
ES 
<Failure fromState="RequesterNegotiation" 
conditionGuard="AnyFailure” 
e + 
<Success fromState="RequesterContract" 
conditionGuard="Success” 
ss > 
<Failure fromState="RequesterContract" 
conditionGuard="AnyFailure” 
ES 
</ Activity > 
<RequestOffer ... > 
<Attribute name="currency" EUR /> 
<Attribute name="productNumber" 1234-5678 /> 
<Attribute name="productName" Notebook Computer /> 
<Attribute name="productDescription" Mobile ... /> 
</RequestOffer> 
</Transaction> 


Figura 1. Solicitud de ofertas en una negociación de tipo policy-driven. 


dichas políticas para poder determinar, de entre un conjunto 
de posibles situaciones, aquellas que sean potencialmente más 
probables para conducir el proceso de negociación hacia un 
objetivo determinado [10], [11]. La parte más relevante a 
analizar acostumbra a ser el conjunto de atributos incluidos en 
la solicitud de ofertas, así como los resultados de la negocia- 
ción. La figura 1 muestra un ejemplo, inspirado en la familia 
de protocolos propuestos en [9], donde podemos apreciar la 
inclusión de un conjunto de atributos que identificarán el 
objeto asociado al proceso de negociación, así como a las 
entidades involucradas en dicho proceso. 

En el caso de negociaciones donde se requiera el inter- 
cambio de datos de carácter personal, ya sea para la iden- 
tificación del objeto asociado al proceso de negociación, o 
para identificar a las entidades del proceso, es imprescindible 
garantizar un proceso de protección apropiado. La simple 
clasificación e identificación de los datos que requerirán dicha 
protección puede llegar a ser extremadamente compleja. Esto 
se pone aún más de relieve si tenemos en cuenta que incluso 
una dirección IP o un número de teléfono móvil asociado a 
las entidades u objetos del proceso de negociación pueden 
ser considerados como datos de carácter personal a proteger. 
En este sentido, el grupo de trabajo de la unión europea, 
encargado de regular la ley de protección de datos y vida 
privada de los ciudadanos, urge en su dictamen presentado 
en [3] la búsqueda de nuevas soluciones, más allá de la simple 
ofuscación de datos, para garantizar el derecho a la protección 
de datos de carácter personal de este tipo de aplicaciones. 
El objetivo de la propuesta que presentamos a continuación 
es precisamente iniciar el estudio de nuevas soluciones que 
puedan tratar esta problemática. 


TII. INFORMACIÓN PRIVADA EN NEGOCIADORES MÓVILES 


El marco donde se centra nuestra propuesta se caracteriza por 
ser un entorno distribuido en el cual, por un lado, existen 
diferentes proveedores de servicios. Por otro lado, diferentes 
usuarios pretenden acceder a los distintos servicios desple- 
gados. Como paso previo al acceso, se establece un proceso 
de negociación, local al proveedor, en el cual un agente 
móvil representa al usuario. Para ello, el agente negociador 
presenta una política de negociación que contiene información 
referente a éste. Esta información está contenida en una polí- 
tica XACML (eXtensible Access Control Markup Language), 
estándar de OASIS [6] que proporciona un lenguaje basado en 
XML muy flexible y expresivo, para especificar políticas de 
control de acceso, así como el protocolo de petición-respuesta 
asociado. 

Dada la vulnerabilidad que supone que el código móvil se 
ejecute en una plataforma remota y, a priori, no confiable, 
hace que la información referente al usuario, contenida en la 
política de negociación, sea susceptible de ser comprometida. 
En términos de privacidad, esta vulnerabilidad desacredita a 
los agentes móviles a contener una política de negociación con 
información referente al usuario. No obstante, esta política se 
hace necesaria para completar el proceso de negociación. Cabe 
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destacar que cualquier registro de información residual en una 
plataforma podría ser utilizados por un adversario en beneficio 
propio. Surge, pues, la necesidad de controlar el filtrado de 
información de carácter personal. Es más, en ciertos casos 
en que el usuario no confíe lo suficiente en la plataforma 
del proveedor de servicios, se puede sacrificar el resultado 
final de la negociación por la preservación de cierto nivel de 
privacidad. 

Con este propósito, el usuario percibe el riesgo de filtrado 
de información (invasión de privacidad) como un contexto de 
la misma negociación. Hay contextos donde el usuario, ya 
sea por su confianza en el proveedor de servicios o por su 
necesidad de obtener un resultado mejor en la negociación, 
puede estar dispuesto a revelar más información inicialmente 
considerada privada. Así pues, y dentro de cada contexto de 
privacidad concreto, proponemos que el agente móvil encar- 
gado de la negociación lleve una política ad-hoc a la etapa de 
negociación. Cada política que el agente negociador llevará 
consigo contiene información diferente según su grado de 
privacidad. De esta manera, se establece, mediante el contexto, 
el nivel de privacidad bajo el que debe operar el proceso de 
negociación. Aunque pueda parecer tedioso el desplegar una 
política diferente para cada contexto de privacidad, hay que te- 
ner en cuenta que la generación de políticas es completamente 
automática y, por lo general, transparente al usuario. 


IFA. Arquitectura 


El escenario en el que trabajamos está compuesto por distintas 
entidades [1]. En primer lugar, un agente móvil de tipo User 
Negotiator (UN), que es enviado por el usuario a la plataforma 
del proveedor. Su primera tarea es sondear las ofertas de 
los proveedores (fase de descubrimiento), y la segunda es 
la negociación del servicio. En segundo lugar, en el lado 
del proveedor, un agente de tipo Access Negotiator (AN) se 
encarga de negociar, con los UN que llegan, los términos 
de acceso al servicio. Por último, dada la vulnerabilidad que 
supone que un agente acarree información privada, surge la 
necesidad de aparición en el esquema de los agentes de 
tipo User Overseer (UO). Los agentes de tipo UO son los 
encargados de enviar agentes UN para el descubrimiento y 
la negociación de servicios. Estos agentes, además, son los 
encargados de gestionar la información que el UN contiene 
acerca del usuario durante cada fase de la negociación. 
Como vemos en la figura 2, esta arquitectura no solo per- 
mite gestionar la información que es presentada al proveedor 
en cada fase de la negociación, sino también la cantidad 
de información que el agente negociador contiene sobre el 
usuario y, por ello, susceptible de ser comprometida. Se hace 


¿a O Servicel 
User 
Overseer 
O O) Service2 


(uo) 
Figura 2. Arquitectura basada en [1]. 


Usuario 


esencial un mecanismo entre UO y el UN que proporcione 
las funcionalidades necesarias para controlar el intercambio 
de información sensible. Dicho mecanismo se fundamenta de 
la siguiente manera: 


= Definimos formalmente la confianza en el contexto de 
negociación como: 
o: [0,1] (1) 


donde d = 0 significa una total falta de confianza 
asociada a la negociación y a = 1 significa el mayor 
nivel de confianza. 

= Denotamos como Attr; al conjunto de atributos que re- 
presentan al usuario. El usuario está interesado en obtener 
la mejor oferta de varios proveedores. El intercambio 
de datos Attr; durante la negociación entre UN y AN 
se condiciona por ciertas restricciones (por ejemplo, al 
resultado de alguna estrategia previa de negociación). De 
esta manera el UN debería intercambiar gradualmente 
Attr, preservando las preferencias del usuario. 

= El revelado de información durante la negociación debe 
de ser gradual y consecuente al contexto de privacidad. 
Para ello, la criticidad de cada atributo se define como: 


p(Attr;) : [0, 1] (2) 


donde (Attr;) = 0 implica el menor grado de criticidad 
asociado al atributo Attr;, y p(Attr;,) = 1 significa que 
el atributo posee el mayor nivel de criticidad. A su vez, 
el conjunto de atributos cuya criticidad es cero, esto es 
[Attr;|y(Attr,) = 0), representa el conjunto de datos 
públicos que el usuario está dispuesto a intercambiar por 
defecto incluso antes de conocer el contexto de priva- 
cidad. Un ejemplo sobre la relación atributo-criticidad 
puede verse en el cuadro 1. 

= El usuario negocia con todos los proveedores de la misma 
manera. Por ello, inicialmente todos los proveedores se 
consideran no confiables. 

= Dado un contexto de privacidad definido, el usuario 
revela cada uno de los atributos si y solo si: 


p(Attr;) < o (3) 


Es decir, un atributo solo es revelado si su nivel de critici- 
dad asociado es inferior o igual al umbral marcado por el 
nivel de confianza asociado al contexto de negociación. 


En este caso, el UN es el sujeto que realizará la petición 
de la política que mantiene el UO. Asumimos que los agentes 
de tipo UN incluyen la funcionalidad necesaria para realizar 
el proceso de negociación [1] ya que pueden evaluar todas las 
peticiones respuestas y gestionar los contextos. Si aplicamos 


Cuadro I 
EJEMPLO DE LA RELACIÓN ATRIBUTO-CRITICIDAD. 
[| Attr; | u(Attr;) 
attri 0,8 
attra 0,7 
attrz 0,3 
attra 0 
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un refinamiento de políticas, se delega a los UNs la capacidad 
de decisión para controlar el intercambio privado de datos con 
los ANs. Una vez que los UNs son enviados a las plataformas 
de los proveedores, el usuario no puede —ni debe— interferir 
en la negociación. 


IHIFB. Notas de implementación 


El módulo UO, encargado de la generación dinámica de la 
política dependiendo del contexto de privacidad, presenta las 
siguientes funcionalidades: 


= Recibir el nivel de confianza asociado a la negociación. 
El UN debe informar al UO del nivel de confianza 
asociado a la negociación con el proveedor de servicios. 

= Representación de los atributos del usuario junto a su 
nivel de criticidad. El usuario debe, de forma sencilla, 
poder especificar los atributos que lo caracterizan así 
como su nivel de criticidad asociando a cada atributo 
un valor dentro del rango [0, 1]. 

= Contener el patrón de la política de negociación. El UO 
debe contener el patrón de la política de negociación 
que le permitirá, una vez conocido el nivel de confianza 
asociado al contexto de negociación, generar la política 
adecuada. 

= Presentar la lógica necesaria para la generación de la 
política de negociación de forma transparente al usuario. 
Esta lógica actúa sobre el patrón de la política, para 
generar de forma dinámica la política de negociación. 


Para la generación automática de la política en XACML, 
existen varias herramientas que permiten la inclusión de 
código dentro de documentos de texto patrón. La ejecución 
de éste código redunda en un documento de texto alterado 
en el que el código ha sido substituido por el resultado de 
su ejecución. En nuestro mecanismo, usamos la herramienta 
de templating ERB [14]. De esta manera, se incluye, dentro 
de un fichero patrón que contiene la política de negociación 
expresada en XACML, la lógica necesaria, expresada en el 
lenguaje Ruby [15], para la generación de las líneas que 
relacionan los atributos con el usuario dependiendo del nivel 
de criticidad. La generación automática de código XACML es 
una idea análoga a la creación de servicios web dinámicos. 

Previo al proceso de negociación, el usuario debe facilitar al 
UO tanto sus atributos como el nivel de criticidad asociado a 
cada uno de ellos. De la misma forma, el usuario debe facilitar 
el patrón de la política de negociación. Este patrón se compone 
de un documento XACML con cláusulas que contienen código 
en ruby. El usuario únicamente se debe preocupar por incluir 
una llamada a un método llamado expand_attributes. Método 
cuyo resultado de ejecución redunda en la impresión de 
aquellos atributos de usuario cuya criticidad sea menor o igual 
a la cota fijada por el contexto de privacidad. Cuando el UN 
establezca el contexto de privacidad, pedirá al UO que genere 
una política de negociación ad-hoc al contexto. Conociendo el 
contexto de privacidad, el patrón de la política de negociación 
y los atributos referentes al usuario, el UO es capaz de ejecutar 
la lógica incluida en el patrón para obtener la política de 


negociación que será enviada al UN. Una vez recibida la 
política, el UN continuará con el proceso de negociación. 


<Subject> 
<%= expand_attributes %> 
</Subject> 


Figura 3. Patrón de la política de negociación. 


La figura 3 muestra un ejemplo XACML simplificado del 
módulo que regula la revelación de atributos del UO, que 
generará las políticas de negociación del UN condicionadas 
por el contexto de privacidad. En dicha figura se observa que 
la inclusión de los atributos del usuario dentro de la política 
de negociación depende del contexto y se realiza a través de 
la llamada al método expand_attributes. La figura 4 muestra 
el resultado de la ejecución, dónde los atributos reflejados en 
el cuadro I se han incluido en la política de negociación bajo 
un contexto de privacidad o = 0,5. 


IV. CONCLUSIONES 


En este trabajo se ha presentado una solución de protección 
de la privacidad en procesos de negociación basada en un 
modelo de refinamiento de políticas condicionadas. El uso de 
un conjunto de transformaciones dinámicas de las políticas 
delegadas a un conjunto de agentes móviles se ha propuesto 
como mecanismo de implementación. Consideramos que 
nuestra propuesta podría ser también valida para otros 
escenarios, tales como procesos de integración de políticas 
de control de acceso, despliegue de configuraciones para 
sistemas de seguridad, o intercambio de alertas de detección 
en entornos de detección cooperativa. Una presentación más 
elaborada de nuestra propuesta así como su adaptación al 
resto de escenarios será tratada en un futuro informe. 
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Abstract—La comunicación inalámbrica entre vehículos cono- 
cida como Vehicular Ad hoc NETworking (VANET) permitirá 
proporcionar diferentes servicios y principalmente información 
a los conductores de manera que aumente la seguridad, eficiencia 
y confort en la conducción. En este tipo de redes los mensajes 
de advertencia repercutirán en las decisiones que tomen los con- 
ductores mientras circulan por la carretera. Por tanto, cualquier 
mensaje impreciso podría ocasionar pérdida de tiempo a los 
conductores, pérdida de dinero en cuanto a combustible, y en 
el peor de los casos accidentes. Por esta razón, un requisito 
indispensable para su uso es poder determinar si la información 
de tráfico vial que llega al conductor es significativa y de 
confianza. Validar este tipo de información sin que suponga un 
problema de sobrecarga y retardo en la red es casi imposible. En 
este trabajo proponemos una solución para validar la agregación 
de datos utilizando una comprobación aleatoria y probabilista de 
manera que permita descartar y descubrir intentos de ataques. 


I. INTRODUCCIÓN 


En la actualidad las VANETS tienen cada vez más importan- 
cia como motivo de estudio en numerosas investigaciones. Este 
tipo de redes permitirá en un futuro reducir e incluso evitar el 
número de muertes en las carreteras además de proporcionar 
información en tiempo real sobre el estado de las mismas. Por 
ejemplo permitirá a los conductores intercambiar información 
con sus vecinos advirtiendo sobre eventos potencialmente 
peligrosos como podría ser accidentes, obstáculos en la vía, 
etc. Otra utilidad para la que se han estudiado las VANET's es 
la posibilidad de encontrar plazas de aparcamientos libres en 
una determinada zona, evitar o reducir congestiones e incluso 
proporcionar información de las condiciones de tráfico en 
tiempo real. 

Para que todas estas aplicaciones funcionen correctamente, 
es necesario asegurar que la información que circula en la red 
es fidedigna, por lo que será conveniente evitar o al menos 
disminuir el número de advertencias falsas en la misma. En la 
bibliografía actual podemos encontrar artículos que defienden 
la utilización de criptografía asimétrica en VANETS para, a 
través de la firma digital determinar de qué fuente llega la 
información y garantizar su integridad. Otros autores proponen 
la utilidad de criptografía simétrica para cifrar el contenido 
de la información proporcionando privacidad. Finalmente se 
propone el uso de seudónimos para proporcionar privacidad 
protegiendo la identidad de los usuarios. Sin embargo, todos 
estos mecanismos no nos protegen de un ataque sencillo y a 
la vez daino como es la generación de contenido falso. Un 
atacante podría inyectar información que no se corresponde 


con lo que está observando realmente. Por ejemplo, un con- 
ductor que tenga prisa por llegar a su destino, podría intentar 
diseminar información falsa acerca de una congestión en una 
determinada carretera para disminuir el número de vehículos 
que circulan por la misma. 

Es cierto que gracias a la criptografía de clave pública 
sería posible determinar y sancionar al vehículo que presenta 
información falsa como verdadera. Sin embargo, el tiempo 
necesario para afrontar este problema por parte de las admin- 
istraciones públicas hace que esta aproximación no sea útil 
dado que debe ser un mecanismo automático y en tiempo real. 
Para afrontar este aspecto proponemos utilizar la agregación 
de datos. Si bien es cierto que la agregación de datos se 
ha utilizado en muchos artículos como un mecanismo que 
permite disminuir el número de paquetes que circulan en la 
red, nosotros pensamos que además se puede utilizar para 
aumentar la fiabilidad de la información diseminada. En este 
artículo utilizamos la idea de cooperación y agregación de 
datos basadas en un esquema probabilista que proporciona 
seguridad a los datos de manera rápida y fiable. 

La agregación de datos en VANETS ha sido introducida en 
algunos trabajos. En [1] Ibrahim presenta un protocolo para 
la retransmisión de información asumiendo que los vehículos 
forman clústeres. Detalles de velocidad e información se 
intercambian dentro del clústeres y cuando el clúster aumenta, 
los registros de información se agregan. Este mecanismo logra 
reducir la cantidad de datos transmitidos en un grupo de 
coches, pero no incluye mecanismos para combinar datos 
agregados. Otra propuesta de agregación se hace en [2] donde 
se presenta la agregación de varios mensajes que describen 
el mismo evento. Se propone también el uso de mensajes de 
revocación que permita a los vehículos denunciar mensajes 
falsos, un ejemplo sería el no detecta un peligro al entrar en 
una zona para la que se había recibido una advertencia. Este 
mecanismo presenta debilidades en cuanto a posibles ataques 
de adversarios los cuales pueden revocar mensajes que son 
reales. En [3] la solución propuesta se basa en el uso de un dis- 
positivo tamper-proof y consiste en preguntarle a un vehículo 
agregador sobre un registro aleatorio agregado originalmente. 
La principal desventaja de este método es la dependencia 
del tamper-proof dado que un atacante fácilmente podría 
pasar por alto este servicio y componer agregados maliciosos. 
Finalmente [4] propone otro mecanismo para proporcionar 
seguridad mediante agregación en un esquema en el que las 
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calles se dividen en segmentos de tamao fijo correspondientes 
a la cobertura de las seales WiFi. Sin embargo, este criterio de 
agregación emplea una segmentación fija de la carretera. Se 
ha demostrado que este tipo de agregación no funciona bien 
con un gran número de vehículos y áreas más grandes, por 
ejemplo, en grandes atascos que abarquen kilómetros. 

Este artículo se organiza como sigue: en la sección II se 
presentan conceptos básico sobre la agregación de datos y 
los modelos de adversarios. En la sección II presentamos 
la propuesta para generar los paquetes de agregación. En la 
sección IV discutimos acerca de los parámetros que se deben 
tener en cuenta a la hora de generar los paquetes de agregación. 
El mecanismo que permite determinar la autenticidad del 
mensaje se presenta en V. En VI y VII, analizamos el esquema 
y la fortaleza del mismo frente a los posibles ataques y 
finalmente en VIII presentamos las conclusiones. 


IT. CONCEPTOS BÁSICOS 


Durante el estudio de las VANETs hemos realizado diver- 
sas propuestas para fomentar la cooperación y aumentar la 
seguridad en este tipo de redes con autenticación, gestión de 
claves y uso de seudónimos. Sin embargo, no encontrábamos 
herramientas que nos permitieran asegurar que la información 
que se generaba era cierta. Un planteamiento inicial y bastante 
lógico para hacer frente a esta necesidad era proporcionar 
a los nodos de un mecanismo que permitiera verificar la 
veracidad del contenido del paquete en el receptor. El modo 
de funcionamiento consistiría en proporcionar a los vehículos 
un almacén de información de modo que al recibir un paquete 
acerca de un peligro en la carretera, cada vehículo sería capaz 
de determinar la carretera y sentido de circulación donde se 
encuentra el mismo, el tipo de peligro y el nodo origen que 
generó este paquete. Una vez almacenada la información, el 
vehículo receptor debe compararla con otros paquetes que 
haya recibido conteniendo la misma información en la misma 
ubicación pero proporcionada por vehículos diferentes. En 
caso de no tener anteriores registros alertando del mismo 
peligro, el mecanismo de verificación tendrá dos opciones: 


+ Alertar al conductor del peligro y arriesgarse a que éste 
no sea cierto. 

+. No alertar al conductor y esperar a poder contrastar los 
datos pudiendo ocasionar un accidente. 


Almacenar y Extraer 
información 


Procesamiento de 
información 


Fig. 1. Planteamiento Inicial de la Agregación 


Analizando detenidamente estas alternativas vemos que en 
el primer caso, la información podría afectar en la decisión del 
conductor y podría traducirse en gasto de tiempo y/o dinero 
del usuario así como en un aumento de la desconfianza en el 
resto de mensajes que lleguen de la red. En el segundo caso, 
se producirá un retardo considerable debido a la espera de la 
llegada de un número suficiente de paquetes con el mismo 
contenido firmados por diferentes orígenes. Por consiguiente, 
el mecanismo debe ajustar el valor del número de paquetes 
a agregar de manera que el tiempo sea suficientemente corto 
como para advertir al conductor acerca del problema, y sufi- 
cientemente grande como para poder asegurar que el contenido 
de la información es real habiendo sido contrastado por un 
número suficientes de vehículos. 

Aparte de lo mencionado anteriormente, este mecanismo 
requerirá que el vehículo cuente con un importante espacio 
de almacenamiento así como con un mecanismo rápido para 
comparar diferentes registros. Esto supondría otro retardo que 
se le sumaría a la espera de los n paquetes a agregar. Es por 
esto por lo que una simple agregación de datos en el receptor 
no es suficiente para afrontar el problema. 

Consideramos que un adversario es cualquier entidad que 
puede controlar varios vehículos en una cierta área de la red. 
El vehículo atacante puede participar activamente en la comu- 
nicación, es decir, puede enviar y recibir cualquier mensaje de 
agregación dentro de la red. Por una parte, centrándonos sólo 
en el proceso de agregación podemos identificar los siguientes 
ataques: 

. Generar un mensaje individual de información falsa. 
Un atacante puede generar un mensaje en una vía que no 
se corresponde con la información real de su entorno. Por 
ejemplo, decir que circula a 20 km/h cuando en realidad 
circula a 80 km/h, con el objetivo de simular un atasco 
en dicha vía. 

. Descartar un mensaje de agregación. Un atacante podría 
suprimir un mensaje agregado y como resultado no per- 
mitir el buen funcionamiento de la red. 

. Generar un mensaje de agregación falso. Un atacante 
podría crear un mensaje agregado con información arbi- 
traria e inyectarlo en la red como verdadero. 

. Provocar repudio de un mensaje de agregación ver- 
dadero. Un atacante podría alterar alguno de los campos 
que permiten comprobar la veracidad de la información, 
con el fin de que los nodos de la red lo tomen como falso. 


TII. MODELO PROPUESTO 


Debido a las características específicas de las redes vehi- 
culares, la protección de la agregación de datos no es trivial. 
La alta movilidad de las redes hace que la topología cambie 
frecuentemente. Por lo tanto, los mecanismos de seguridad en 
este entorno no deberían asumir la existencia de estructuras 
estables. Pretendemos adaptar mecanismo de seguridad de [4], 
donde se utiliza una combinación de firmas junto con la idea 
de grupos, a una red donde no necesariamente deban formarse 
grupos explicitamente. Además se debe tener en cuenta que en 
la etapa de inicialización de estas redes no todos los vehículos 
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contarán con un dispositivo que les permita participar en la red 
como nodo y por lo tanto el esquema propuesto debe adaptarse 
a los distintos tamaos que presentará la red durante su vida. 
Este mecanismo permite la agregación de cualquier tipo de 
información, ya sea sobre incidentes en la carretera o con 
información relacionada con una conducción más confortable, 
etc. Es un mecanismo genérico que sirve tanto para redes 
autónomas como para aquellas en las que se requiere de 
una autoridad certificadora [5] permitiendo cualquier tipo de 
agregación que pueda hacerse en este tipo de redes. Este 
mecanismo de seguridad permite detectar ataques y mitigar 
sus efectos. 

En nuestro esquema de agregación de datos, tenemos en 
cuenta diferentes aspectos de funcionamiento de los nodos: 
uno será aquel en el que mientras los vehículos circulan 
se encuentran con el obstáculo en la carretera y generan 
automáticamente mensajes de advertencia de peligro, otro será 
el de la recepción del paquete anterior confirmando que existe 
un peligro, y finalmente estarán los vehículos que reciban un 
paquete con la información y su respectiva confirmación. En 
el esquema básico cada vehículo retransmitía un mensaje de 
advertencia firmado, lo que suponía una considerable sobre- 
carga de la red, además del retraso resultante de la verificación 
y comparación de los datos procedentes de diferentes orígenes 
en el receptor. En este nuevo esquema proponemos combinar 
las firmas generadas por diferentes vehículos que avisen de un 
mismo problema. De este modo, combinamos las firmas y las 
agrupamos en un único mensaje, obteniendo como resultado 
un uso más eficiente de la comunicación inalámbrica. Sin 
embargo también este método presenta varios inconvenientes. 
Por una parte, al hacer una combinación de firmas, el tamao 
del paquete irá creciendo a medida que aumente el número de 
vehículos que confirmen la información por lo que volvemos 
a sobrecargar el canal. Por otro lado, el hecho de que la 
información esté firmada no significa que sea correcta. El 
receptor deberá en dicho esquema comprobar las firmas, lo 
que significa un retardo en la comprobación, que igualaría o 
incluso superaría el tiempo empleado por el modelo básico. 
Para solucionar este problema, proponemos aquí un tamao 
máximo de firmas que pueda contener el paquete de manera 
que no pueda crecer de manera infinita, y una granularidad 
basada en la idea de [6] donde se definen rangos dentro de los 
que podemos y debemos encontrar información. Finalmente, 
para solucionar el retardo ocasionado por la comprobación de 
firmas proponemos un esquema probabilista para comprobar 
algunas firmas. Todos estos mecanismos de seguridad se 
detallan a continuación. 


TV. TAMAO Y GRANULARIDAD 


Tal cómo se comentó en el apartado anterior, el tamao del 
paquete se debe restringir a un máximo T' que no sature el 
canal y que permita transmitir el paquete de manera rápida. 
En este caso el tamao deberá ser lo suficientemente grande 
como para tener suficientes testimonios de un mismo peligro 
sin exceder el máximo soportado por el canal inalámbrico. 
Teniendo esto en cuenta podemos definir ciertos criterios a 


Fig. 2. Área de Peligro 


la hora de introducir las firmas en un paquete de agregación. 
Por una parte, proponemos insertar en la primera y segunda 
posición del paquete los extremos que delimitan la zona de los 
datos detectados a agregar. Considerando que los datos agre- 
gados representarán un área donde los vehículos comparten 
valores comunes, se podrá obtener un área de los datos a 
agregar asociada a la localización del evento que se quiere 
difundir. De este modo si un vehículo es capaz de presentar 
información firmada validada sobre los bordes que delimitan 
un accidente en una agregación, esta información se puede 
tomar como válida. En la figura 2 los vehículos V1 y el V6 
delimitan el área de peligro en un incidente. 

Especialmente si el área agregada es grande, aadir valores 
de los bordes solo indicará que el dato agregado es válido, 
pero un adversario podría proporcionar valores para los bordes 
y no para el interior del área y de este modo mentir sobre 
la existencia un atasco. Se necesitarán más firmas que se 
correspondan con el interior del área. Para esto, además de 
delimitar el tamao del paquete a 7 firmas, se propone utilizar 
una granularidad S que consistirá en dividir las posiciones 
delante y detrás del incidente en regiones o celdas actuando 
del siguiente modo. Dependiendo del tipo de carretera el 
parámetro de granularidad S será mayor o menor teniendo 
en cuenta que cuanto más pequea sea la granularidad, mayor 
será la seguridad. El objetivo es seleccionar las firmas de 
manera que estén igualmente distribuidas en toda el área 
agregada. Así, antes de agregar una firma deberá estar a 
distancia S de otras dos como mínimo. En caso contrario 
no se introducirá o bien se cambiará la existente por ésta. 
Con esto se pretende tener información sobre un mismo 
incidente actualizada, distribuida y más fiable. A la hora de 
generar un paquete de agregación, un nodo deberá determinar 
la granularidad propuesta para el mismo. Esta granularidad 
dependerá del tipo de vía, siendo más grande en autopistas y 
más pequea para carreteras convencionales. Una vez definida 
la granularidad, las firmas empezarán a agregarse. Si un nodo 
es extremo lo indicará en la primera y segunda posición del 
paquete, y a continuación se irán aadiendo las diferentes firmas 
en los puntos de granularidad permitiéndose cierta variación. 
La estructura del paquete se define como sigue. El nodo que 
genera el paquete, aadirá la granularidad S así como una 
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Fig. 3. 


Generación de paquete agregado 


posible variación de la misma AS y reenviará el paquete, esto 
se corresponde al paquete generado por Vl en la figura 3. 
Cada nodo que reciba la información y detecte el mismo 
problema firmará el contenido y lo colocará en función del 
rango de granularidad al que pertenezca, en la figura 2 V1 y 
V6 eran los extremos por lo que sus firmas ocupan la primera 
y segunda posición. Posteriormente V4 agrega su firma y 
finalmente V2 que lo hace en la tercera posición dado que 
según la granularidad es la posicion que le corresponde. 

Los nodos que son capaces de detectar un peligro no 
comprobarán las firmas contenidas en el paquete, sino que 
simplemente firmarán indicando que están de acuerdo con 
la información e introducirán la posición S, en la que se 
encuentran con el fin de aligerar el proceso de creación de 
los paquetes de agregación. En cada agregación los nodos 
deberán primero ver la información, y si están de acuerdo 
con la misma, el primer paso será comprobar si son extremos 
o no. Nótese que los segmentos $ se calculan respecto a la 
posición donde se generó el mensaje M y no respecto a los 
extremos, por lo que será fija. Si el nodo actual resulta ser 
extremo, cambiará el primer o segundo campo. Si el nodo 
no es extremo buscará la posición 5; a la que corresponde y 
firmará. Si resultara que la posición ya está ocupada, sólo se 
actualizará la información. 


V. VERIFICACIÓN PROBABILISTA 


La verificación probabilista sólo se aplicará en aquellos 
vehículos que no son capaces de comprobar la información que 
les llega, es decir, cuando reciben un mensaje de advertencia 
en un punto que no es alcanzado por la cobertura de su 
antena. En este caso, el vehículo antes de tomar la infor- 
mación como cierta deberá comprobar que está firmada por 
diferentes vehículos. Como ya se ha comentado, es ineficiente 
comprobar todas las firmas contenidas en un paquete, pero 
si será necesario verificar la información antes de darla por 
válida y enviársela al conductor. Para solucionarlo nosotros 
proponemos verificar sólo un pequeo número de firmas. En 
esta sección, introducimos un esquema de autenticación que 
puede asegurar que el mensaje es auténtico sin verificar todas 
las firmas del mensaje recibido basándonos en COMET [7]. 

El algoritmo que se ejecuta en un vehículo se detalla en 
la figura 4 donde se utilizan hilos dado que son procesos 
más ligeros que permiten la ejecución concurrente. En el 
algoritmo, H;, H; y H, son tres hilos donde 2,3,k =1,2,...n, 
con ¿ 4 j % k. Cuando un vehículo recibe un mensaje se 
lanzan tantos hilos como firmas contenga el mensaje. Nótese 
que antes de este proceso se habrá comprobado si contiene 


//Se reciben el mensaje M con las firmas FL...Fn 
int Programa Principal 
21 //Se crea un vector de tamaño igual al número de firmas a comprobar 
bool P[c]; 
//Se crea un vector con tantos hilos como firmas hayan 
hilo H[n]; 


for (cada hilo ¡ que le toque comprobar )4 
/*Se elige si el hilo i comprueba con probabilidad p o 
no comprueba con probabilidad 1-p*/ 
if (H[iJ=1 ) 
PE I=H[iI(CompruebaFirma(F,M)); 
j++ 


E 


if(Todo P= verdadero)K4 
return mensaje fiable 
y 
else 
t 
if (Todo P = falso) 
return mensaje no fiable 
else 
return comprobar reputación 


3 


— /*Función que devuelve verdadero si la firma se corresponde con el testo 


y falso si no se corresponde”*/ 
bool function CompruebaFirma(Firma Fi,Texto M ) 


=p 


HL[i] verifica Fi 
if Fi es valid then 
return true; 
else 
return false; 
end if 


Fig. 4. Algoritmo de Verificación Probabilista 


suficientes firmas como para determinar que el mensaje se ha 
contrastado con un número significativo de vehículos. Cada 
hilo A; determina si verifica la firma correspondiente con una 
probabilidad de verificación p. Si A, realiza la verificación de 
la firma y es correcta devolverá un 1 indicando la veracidad 
de la firma y en caso contrario devolverá un O. El resultado de 
todos aquellos hilos que han tenido que comprobar el mensaje 
se introducirá en una estructura P que esperará a que todos los 
hilos terminen su comprobación. Si todos los campos de P son 
verdaderos es que todas las firmas verificadas eran correctas 
por lo que el mensaje es válido. Por otro lado, si algunas de las 
comprobaciones resultaran incorrectas, podría significar que 
el mensaje es falso. En este punto, planteamos la posibilidad 
de utilizar la información de reputación almacenada por los 
vehículos y el número de respuestas de mensaje no fiable 
procedentes de diferentes vehículos que tenemos. Si hay 
una mayoría que indica que el mensaje es falso se tomará 
como falso y si ocurriera el caso contrario se tomaría como 
verdadero. Si existiese un empate o una cantidad dudosa, se 
comprobaría la reputación de los nodos, fiándose de aquellos 
que tienen buena reputación en cuanto a la cooperación en la 
red. 
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VI. ANÁLISIS DE LA SOLUCIÓN 


A continuación se analiza la solución propuesta. Para garan- 
tizar que un mensaje M, es fiable, al menos una de las firmas 
del mensaje debe ser verificada. La probabilidad de que exista 
al menos una verificación debe ser un valor muy cercano a 1. 
Sin embargo, desde el punto de vista de la agregación de datos, 
una sola comprobación no es suficiente. Supongamos que se 
recibe un mensaje M, con n firmas falsas y una verdadera y 
se trata de un mensaje falso. Si un hilo HA; verifica la firma 
verdadera, podría asegurar que este mensaje es verdadero. Por 
tanto, deben existir al menos dos comprobaciones de firmas 
para verificar un mensaje. Según las coordenadas del mensaje, 
a menos que se haya generado en un extremo, existirán firmas 
pertenecientes a vehículos que se encontraban por delante del 
mensaje generado y firmas por detrás. En caso contrario se 
dividirán por la mitad. Sea n el número total de firmas que 
contiene un paquete O, dividimos el número de firmas en dos, 
¡es el número de firmas de los vehículos que se encontraban 
delante de donde se generó O (o la primera mitad) y n-i el 
número de firmas detrás de O (o de la segunda mitad). Sea A; 
el suceso de que hay ¡ firmas que se generaron delante de O 
y n-i detrás. Sea B el evento de que al menos se comprobarán 
dos de las firmas del mensaje, una de las cuales estará entre 
las que se generaron delante de O y la otra detrás, esto evita 
comprobaciones de firmas que se generaron en una misma 
zona. Entonces la probabilidad Pr [B) puede ser representada 
como una función de n y p como: 


Pr(B) = izo Pr1B14;) - Pr (4) 
(1) 


=14+(1-9)"-2:(1-8y" 


Donde Pr (B|A/) = (1 (1=p)) — (1 (1-p)"=")), y 
(1 — p)' es la probabilidad de que ninguna de las ¡ firmas por 
delante de donde se generó O serán verificadas, 1— (1 — p)' 
es la probabilidad de que al menos una firma de las generadas 
será verificada y 1— (1 — p)”"* la probabilidad de que al 
menos una de las firmas por detrás de donde se generó O será 
verificada; 


Prías = (6) (1/2 -(1-1/2 


porque la posición donde se genera cada firma es indepen- 
diente del número de firmas que se generan delante y detrás 
de donde se generó O. Puesto que la posición de cada firma 
a verificar es independiente y el número de firmas delante y 
detrás sigue una distribución binomial con parámetro n y . El 
objetivo es hacer Pr [B) tan cercano a 1 como sea posible. 

En la figura 5 se muestra la relación entre Pr(B), p y 
n, donde se puede ver como Pr(B)j aumenta cuando p y 
n aumentan. Pr(B) se aproxima rápidamente a 1 cuando p 
es un valor pequeo. Además podemos concluir que cuando 
Pr(B) es fija, p es inversamente proporcional a n. Nuestro 
objetivo es cambiar p de manera que Pr (B| se aproxime a 1 
tanto como sea posible. Por otro lado, cuando Pr (B| se haya 
aproximado lo suficientemente a 1, intentamos hacer p lo más 


Probabilidad de Éxito 


Fig. 5. 


pequea posible porque un valor pequeo de p implica que un 
vehículo pueda potencialmente disminuir el procesamiento. 

A la hora de seleccionar el número de firmas que contendrá 
el paquete hay que tener en cuenta el tamao máximo que puede 
ser utilizado para este tipo de redes así como el número de 
firmas que se debe utilizar para asegurar la información. Para 
el primer caso tenemos tamaos de paquetes desde 256 bytes 
hasta 1500 bytes. Como en este tipo de redes se puede llegar 
a generar una gran cantidad de paquetes sería conveniente no 
utilizar el valor máximo dado que con un par de paquetes se 
saturaría el canal. Si tenemos en cuenta la función resumen que 
se va a utilizar para las firmas así como dejar unos 100 bytes 
para el contenido del mensaje, estaríamos hablando de 156 
bytes en el peor caso y de 1400 en el mejor. Utilizando como 
función resumen SHA-1 que genera un resultado de 160 bits 
o lo que es lo mismo 20 bytes, generaríamos 7 firmas como 
máximo en el peor caso y 70 firmas en el mejor. 

Para que cada vehículo elija un valor de p apropiado para 
los diferentes valores de n posibles, utilizamos el parámetro 
k = n-p para representar la proporción inversa entre p y n. Así 
k representa el promedio de firmas que un vehículo verifica 
porque n es el total de firmas contenida en el paquete y p es 
la probabilidad de verificación. Si encontramos un valor de k 
adecuado, entonces el valor de p correspondiente puede ser 
determinado fácilmente. Basándonos en (1), podemos obtener 
un relación entre Pr(B) y n en términos de diferentes k, de 
forma que el valor de p puede ser determinado. Teniendo en 
cuenta que la probabilidad p tendrá como valor máximo 1 y 
habíamos dicho que como mínimo n sería 7, en la figura 6 
vemos que con k=7, Pr [B) es bastante cercano a 1 pero no 
lo suficiente. Sin embargo con k=10 la probabilidad es mucho 
más cercana a 1 cuando el paquete tiene 9 firmas o más. Por 
lo tanto, podemos fijar el valor de k a un valor constante, por 
ejemplo 10, y calcular p como k/n, que en este caso sería 
10/n, y de ahí modificar p según el valor de n. Por ejemplo, 
un vehículo que recibe un mensaje con 20 firmas, verificará 
cada firma con una probabilidad de 10/20. En caso de que el 
paquete contenga menos de 10 firmas, la probabilidad p para 
cada firma será del 100% 

Teniendo en cuenta el número de firmas mínimo que puede 
contener un paquete para maximizar la probabilidad Pr (Bj) 
además de calcular las probabilidades y el número de firmas 
máximos que cabe en un paquete, podemos determinar qué 
función resumen podemos utilizar en este tipo de redes. Si 
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1+(1- (yx 2% 0-12) ex —] 1 + (1 - (10/x))* x- 2 * (1 - (10/xP! 2) *x— 


Función Resumen Tamaño del paquete Tamaño para M Tamaño para Firmas N?2 de firmas posibles 


SHA-1 
SHA-256 


512 


MD5 
1024 
SHA-256 


Fig. 7. 


SHA-1 


Funciones Resumen 


nos fijamos en la tabla de la figura 7 y teniendo en cuenta que 
para una función hash utilizando MDS se obtiene un resultado 
que ocupa 16 bytes, para SHA-1 20 bytes y para SHA-256 
32 bytes y dejando un tamao de 100 bytes para datos en el 
paquete, vemos el número de firmas que podemos aadir en 
cada uno de los casos. Por ejemplo, con un paquete de 512 
bytes y utilizando un total de 9 firmas con SHA-1, tenemos 
espacio suficiente para agregar las firmas necesarias. Incluso 
con este valor se permite utilizar una función resumen SHA- 
256 con paquetes de 512 y de este modo aumentar la seguridad 
de la función resumen. 


VII. ANÁLISIS DE POSIBLES ATAQUES 


Como se presentó en la sección II se pueden intentar 
varios ataques con el fin de hacer que la red no funcione 
correctamente. El primer caso, donde se comenta la posibilidad 
de generar un mensaje con información falsa, queda descartado 
por la propia estructura de una agregación de datos. Los 
vehículos firmarán el mensaje si son capaces de detectar el 
problema que se especifica en el propio mensaje. El segundo 
ataque consistía en descartar un mensaje de agregación. Para 
solucionar este problema se han propuesto diferentes esquemas 
de cooperación [8]. Sin embargo el dao que pueda ocasionar 
a una agregación de datos no será demasiado grande dado que 
no sólo se generará un único paquete de agregación. El tercer 
ataque que consiste en generar un mensaje de agregación falso 
es posible llevarlo a cabo mediante la utilización de firmas 
de otros adversarios. Sin embargo, cuando un vehículo que 
no tiene acceso a dicha información recibe un mensaje de 
agregación tendrá que llevar a cabo dos comprobaciones. Por 
una parte, y con respecto a la agregación, deberán existir dos 
firmas correspondientes a los bordes del incidente, que pueden 
ser generadas por el propio adversario de manera correcta, 
pero aparte de eso, las firmas agregadas deberán cumplir con 


la granularidad y además se comprobará que las firmas se 
corresponden con el mensaje. 


VII. CONCLUSIÓN 


En este artículo se plantea la necesidad de afrontar un prob- 
lema de seguridad existente en VANETS, que consiste en de- 
terminar si la información de tráfico vial que llega al conductor 
es significativa y de confianza. En concreto, proponemos un 
esquema para generar los paquetes de agregación de forma 
que sean seguros y difíciles de suplantar por un adversario. 
Para ello combinamos diferentes ideas en un nuevo esquema 
de agregación de datos de manera que aquellos vehículos 
que estén de acuerdo con la información generada firmen el 
paquete. Para evitar que el paquete crezca indefinidamente, las 
firmas se generarán siguiendo una granularidad definida según 
el tipo de vía y haciendo imposible por parte de un atacante 
la modificación de la misma. Á su vez se generan dos firmas 
que delimitan la región. Si más de un vehículo coincidiera 
en granularidad se propone la actualización y reemplazo de 
firmas en una misma granularidad para mantener actualizada 
la información. Por otra parte, cuando el paquete agregado 
llegue a un vehículo, éste podrá verificar su información 
comprobando la firma. Para evitar el retardo que supondría 
tener que comprobar todas las firmas se propone un esquema 
probabilista de manera que se elige comprobar alguna de las 
firmas siendo el número de firmas a comprobar un punto de 
equilibrio para asegurar que la información es cierta, y no 
provoca retardos en la obtención de la información. 
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Abstract—En este trabajo se analizan algunos problemas in- 
herentes a las VANETS debidos la falta de infraestructura central 
y a que los usuarios están en constante movimiento, dificultando 
conexiones, enrutamiento y seguridad de las comunicaciones. 
Además, otro inconveniente que también debe ser resuelto es 
la escalabilidad ya que el número de vehículos que circulan 
por la carretera es cada día mayor. Ante situaciones de tráfico 
denso de vehículos que ocasionarían que las comunicaciones se 
degradasen, este trabajo propone el uso de grupos como solución 
al intercambio de información ya que utilizando grupos se puede 
fraccionar la VANET en pequeñas subVANETSs que permiten por 
una parte no enviar la misma información por múltiples caminos, 
y por otra, usar criptografía de clave secreta. De esta forma se 
logra mejorar la eficiencia y la seguridad de las comunicaciones. 
En particular aquí se proporciona una definición completa de los 
procesos de creación y administración de grupos en VANET:s, así 
como de la forma de tratar la información cuando los vehículos 
pertenecen a un grupo. 


IT. INTRODUCTION 


Una red ad-hoc vehicular o VANET (Vehicular Ad-hoc 
NETwork), como su propio nombre indica, es una red ad- 
hoc donde sus nodos se corresponden con vehículos. Concre- 
tamente se trata de una red de tipo MANET (Mobile Ad- 
Hoc NETwork), es decir, una red móvil ad-hoc formada 
espontáneamente por nodos en pleno movimiento. 

La seguridad vial es un problema de vital importancia clasi- 
ficado por la comunidad Europea como uno de los objetivos 
prioritarios. Existen múltiples situaciones en las que las comu- 
nicaciones entre vehículos ayudarían a prevenir accidentes y 
evitar atascos. Cada año se producen más accidentes de tráfico, 
debido en gran medida a que cada año existen más vehículos 
en la carretera. Proporcionar información al conductor acerca 
de los peligros existentes podría ayudar a prevenir y evitar 
riesgos. Sólo un 6% de los accidentes es inevitable y está 
fuera del alcance de las mejoras tecnológicas. El resto podría 
evitarse usando dispositivos que alertaran al conductor de los 
peligros de la carretera. Además, las VANETs ayudarían a 
evitar atascos, ahorrando así tiempo, dinero, contaminación 
del medio ambiente, reservas de petróleo y destrucción del 
paisaje por construcción de carreteras. 

Existen varias características de las comunicaciones que 
deben ser protegidas en cualquier red inalámbrica: autenti- 
cidad, privacidad, anonimato, cooperación, bajo retardo, es- 
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tabilidad de las comunicaciones, etc. En particular, en las 
VANE!Ts los escenarios son muy cambiantes, desde carreteras 
comarcales sin apenas tráfico hasta ciudades o autopistas 
plagadas de vehículos donde el número de comunicaciones es 
casi infinito [8], [7], [1]. En este trabajo definimos esquemas 
para la utilización de grupos en VANETs que permiten a 
la vez optimizar considerablemente las comunicaciones en 
situaciones de tráfico denso, y definir claves secretas de grupo 
con las que se podrá usar criptografía de clave secreta para 
distribuir información de forma rápida y segura. 

En cuanto a la utilización de grupos o clusters en VANET:s, 
el trabajo [2] presenta un análisis teórico de un algoritmo 
de agrupamiento basado en la estabilidad direccional. En 
[4] se proponen clusters donde el líder es el nodo que se 
encuentra en medio del grupo y tiene el identificador más 
bajo. [3] describe clusters con 4 fases: NoDecidido, Miembro, 
Entrada y CabezadeCluster. En [10] se proponen clusters 
para maximizar el avance de la información retransmitida 
y evitar interferencias. [5] propone la firma de grupos para 
proteger la privacidad, siendo las Road-Side-Units (RSU) los 
distribuidores de claves. Estos documentos no definen en 
detalle cómo se producen los cambios en el grupo, lo que 
es nuestro principal objetivo. 

En la sección II se mencionan algunas aplicaciones y 
tipos de enrutamiento que pueden usarse en estas redes. A 
continuación se proporciona una definición de grupo y una 
propuesta para el establecimiento de clave secreta compartida. 
En la sección IV se explican en detalle las distintas fases de 
grupos que se distinguen en este trabajo: Detección, Creación, 
Elección, Entrada y Final. La sección V describe cómo se re- 
alizan las comunicaciones en el grupo. Finalmente se detallan 
las conclusiones. 


TI. APLICACIONES Y ENRUTAMIENTO 


Las aplicaciones de las VANETs en seguridad vial puede 
clasificarse en tres categorías: 


+. incidentes dinámicos (infracción grave detectada, circu- 
lación en sentido contrario, vehículos de emergencia, etc.) 

e incidentes estáticos (límite de velocidad, obras en car- 
retera, etc) 

. gestión de incidentes (accidente, atropello, etc.) 
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Otras aplicaciones más avanzadas son la notificación de 
servicios, los esquemas de asistencia cooperativa al conductor 
y los sistemas de monitorización. Por último, existen una serie 
de aplicaciones interesantes que aportan valor añadido a las 
VANET:s, incluyendo por ejemplo el anuncio de zonas de in- 
terés, la comunicación interactiva entre las OBUs (On-Board- 
Units) situadas en los vehículos o el pago electrónico, entre 
otras. Una característica importante de este tipo de servicios 
y aplicaciones comerciales es que no deben interferir con las 
aplicaciones de seguridad vial ya que éstas son prioritarias, 
tal y como queda reflejado en el orden de ejecución descrito 
en el DSR (Dedicated Short Range) incluido en el borrador 
de estándar para VANETs IEEE8S02.11p WAVE (Wireless 
Access for Vehicular Environments). Diferentes tipos de en- 
caminamiento para la entrega de información dentro de una 
VANET son necesarios según el tipo de comunicación y su 
aplicación. Los modos más relevantes son los siguientes: 


e Unicast: Envío uno a uno, es decir asociación con un 
único emisor y un único receptor. 

+. Broadcast: Difusión de uno-a-muchos, donde se pretende 
que la información sea recibida por todos los posibles 
nodos receptores de la red. 

e Multicast: Envío de uno-a-muchos, donde la información 
replicada y se envía a un conjunto específico de recep- 
tores. 

+. Geocast: Multidifusión especial limitada basada en las 
posiciones geográficas de los nodos. 

+ Anycast: Envío en el que sólo uno de los posibles 
receptores se elige para recibir la información. 


TIT. GRUPOS Y CLAVE SECRETA 


Llamamos aquí grupo a un conjunto de nodos (vehículos 
con OBU) que se encuentran cercanos entre sí, situados en 
una zona geográfica, y dentro de la cobertura de al menos 
uno de ellos. Definiremos la distancia entre nodos en función 
del número de saltos (hops) mínimos necesarios para la 
comunicación entre ellos. Para pertenecer al mismo grupo 
todos los nodos deben estar a distancia uno de al menos 
uno de ellos. Para hacer más simple y ligera la gestión del 
grupo, uno de esos nodos que recubren el grupo será elegido 
como líder del grupo. Por tanto, los grupos se basan en la 
proximidad geográfica y están acotados a un salto de distancia. 
El líder de grupo será el encargado de gestionar la información 
y las conexiones que se establecerán dentro y con su grupo, 
delegando trabajo a otros vehículos si fuese necesario. 

La gestión de grupos debe cumplir dos requisitos: minimizar 
el consumo de recursos y en particular el intercambio de 
mensajes, y tener en cuenta la topología altamente dinámica 
de la red, requiriendo actualización de la pertenencia al grupo. 
Se exige un mínimo de vehículos para constituir un grupo. 
En particular, los vehículos formarán grupos según celdas 
dinámicas donde el líder es el vehículo con tecnología VANET 
que haya iniciado el grupo que tenga mayor número de vecinos 
en el momento en el que el anterior líder caiga por debajo del 
umbral definido para la formación de grupo. Esta definición 
espontánea de los grupos en general está en función de la 


velocidad media de la vía y la dirección en la que circulan 
los vehículos, de forma que los vehículos que circulen a una 
velocidad cercana a la media en la mayor parte de los casos 
no cambian de grupo durante su trayecto. 

Los grupos sólo serán usados cuando las condiciones de la 
vía así lo requieran, por ejemplo, con tráfico denso, atascos o 
carreteras muy concurridas, donde la densidad de vehículos en 
una zona geográfica hace que el número de comunicaciones 
sea excesivamente grande provocando colisiones en la señal de 
la información enviada y degradando notablemente la calidad 
de las comunicaciones, así como para posibilitar el uso de 
criptografía de clave secreta en VANETs. En los casos donde 
el número de vehículos sea bajo y no exista saturación de las 
comunicaciones no se activarán las comunicaciones por grupo. 

Si n denota el número de nodos, la propuesta basada en 
grupos implica una significativa reducción en el número de 
envíos broadcast. En particular, sin la utilización de grupos 
cada uno de los n nodos envían mediante broadcast cada 
dato a enviar de forma que el número total n(n — 1) de 
comunicaciones crece rápidamente debido a las colisiones 
entre paquetes. Sin embargo, utilizando el esquema de grupos 
propuesto, se generan 3 conexiones por grupo para cada dato 
enviado ya que se reducen las colisiones. La primera conexión 
va desde el vehículo que produce la información hacia el líder 
(a no ser que la produzca el mismo líder). A continuación el 
líder hace un envío a todos los vehículos del grupo. Por último, 
habrá otra conexión entre el líder y otro vehículo (el que se 
encuentre en la mejor posición para continuar la difusión de la 
información). Por tanto se generarán un total de 3* (número 
de grupos) envíos de información por cada paquete de datos 
en las zonas de alta densidad de tráfico. 

La mayoría de las referencias bibliográficas proponen como 
solución criptográfica para las comunicaciones en VANETS el 
uso de una Infraestructura de Clave Pública, con certificados 
expedidos por una Autoridad Certificadora. Esta solución 
supone que a cada nodo se le asigna un par de claves 
pública/privada que se almacena en un dispositivo tamper- 
proof. La propuesta de gestión de las comunicaciones basada 
en grupos permite el uso de criptografía de clave secreta ya que 
posibilita a los miembros del grupo llegar a un acuerdo sobre 
una clave secreta compartida. La comunicación con clave 
secreta compartida y la cercanía de los miembros del grupo, 
que se comunican en modo promiscuo, permite a los nodos 
pertenecientes a un grupo controlar que tanto el líder como 
sus compañeros de grupo actúan correctamente. En particular 
en el esquema descrito a continuación los nodos que forman 
un grupo deben generar una clave secreta compartida. Para 
ello el esquema que proponemos se basa en la dificultad del 
problema de logaritmo discreto, consistente en describir el 
valor de S a partir del conocimiento de g*(mod p), y y p. Este 
problema es la base del conocido método de Diffie-Hellman 
para el intercambio secreto de claves entre dos usuarios, de 
forma que la propuesta de este trabajo puede verse como una 
generalización de dicho método para un conjunto de usuarios. 

Por otra parte el esquema se basa en el uso de esquemas de 
compromiso de bits. Los nodos se comprometen frente al líder 
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con su aportación a la clave secreta compartida de forma que el 
líder no pueda cambiar dicha aportación, ni leerla. Asímismo, 
el uso del esquema de compromiso hace factible el intercambio 
de información pública para la generación por cada nodo del 
secreto compartido sin que el secreto de la clave compartida 
ni de las distintas aportaciones corran peligro. 

La notación utilizada en el esquema es: 
: función hash. 
: número primo. 
: elemento generador de Z,,. 
: nodo. 
L : líder de grupo. 
S; : entero aleatorio seleccionado por ¿ entre O y p-2. 
g?* : compromiso público de ¡ con entero S;. 


1) Cada nodo 1 que acepte formar parte del nuevo grupo 
envía al líder L su compromiso g** (mod p) 

2) El líder L hace broadcast del 
gg ias 

3) Cada nodo ¿ que acepte formar parte del grupo puede 
construir la clave secreta compartida K' ya que cono- 
ciendo S;, puede calcular el inverso de S; (mod p — 1) 
y por el teorema de Euler gal, de forma que 

SiSL — q (e ES) 


De esta forma la clave del grupo es generada mediante las 
aportaciones de los primeros miembros del grupo. Mientras el 
grupo exista, las nuevas incorporaciones de nodos se realizan 
mediante el envío cifrado de esta clave secreta con la clave 
pública de cada nuevo nodo. 


E 


mensaje 


K= gar * T;+L9 


TV, FASES DE GRUPOS 


Las VANETs son redes inalámbricas en las que puede 
haber un gran número de conexiones altamente volátiles entre 
vehículos. Por este motivo se hace necesario definir en detalle 
la forma en la que deben actuar los vehículos según la 
situación en la que se encuentren. En el presente trabajo se 
exponen diferentes fases en las que puede encontrarse un 
vehículo según la vía y la situación en la que el vehículo se 
encuentre. Concretamente se distinguen: Detección, Elección, 
Creación, Entrada y Salida del Grupo. El esquema global 
de la vida de la red propuesto en este artículo es como 
sigue. Inicialmente todos los nodos comienzan en la fase 
de Detección de Grupo. Tras ésta, pueden entrar en la fase 
de Creación o de Elección de Grupo, dependiendo de las 
circunstancias. Tras la fase de Creación de Grupo, el nodo 
sería el líder de grupo y entraría en la fase de Vida del Grupo. 
Tras la fase de Elección de Grupo, el nodo entraría en la fase 
de Pertenencia a Grupo. El esquema es cíclico dado que tras 
terminar las fases de Vida de Grupo o Pertenencia a Grupo el 
nodo comienza nuevamente en la fase de Detección de Grupo. 


A. Detección de Grupo 


Esta primera fase es en la que cada vehículo estará nor- 
malmente, es decir, cuando no se encuentra en una situación 
de tráfico denso. La figura 1 muestra cómo el vehículo 
comprobará cada cierto tiempo el número de vecinos, y el 


número de líderes entre ellos. En caso de existir al menos un 
vecino que sea líder de un grupo el nodo pasará a la fase de 
elección de grupo, y en caso contrario a la fase de creación de 
grupo. Esta fase no genera ningún tipo de tráfico de control 
dado que toda la información necesaria está contenida en los 
beacons que lanzan los usuarios para su descubrimiento. 


Fig. 1. 


Detección de Grupo 


B. Elección de Grupo 


En esta fase se supone que el vehículo ha encontrado entre 
sus vecinos al menos un nodo que es líder de algún grupo. 
En caso de que sólo haya un vecino que es líder de grupo, la 
elección es automática. En caso de que haya varios, el nodo 
tendrá que elegir a cuál de ellos unirse. En la figura 2 se puede 
ver cómo resuelve las distintas posibilidades que pueden darse. 
Para ello tendrá en cuenta tres valores para cada grupo j: 


+ La densidad A (j) de vehículos. 
+ La calidad media de la señal B (¿) de los vehículos. 
+ Los segundos C (j) que ha estado conectado al líder. 


Todas estas variables tomarán valores que serán determina- 
dos a partir de pruebas y simulaciones donde se comprobará 
cuál de estas características es más importante. Una vez 
elegido el grupo al que se va a conectar, el vehículo envía 
una petición de entrada junto con su clave pública al líder 
del grupo el cuál después de autenticarlo, le enviará la clave 
secreta del grupo cifrada con la clave pública del vehículo 
receptor, momento a partir del cual dicho vehículo pasa a 
formar parte del grupo. 


C. Creación de Grupo 


En la fase de creación de grupo (figura 3) el vehículo no 
tiene cerca a ningún líder de grupo. Debe comprobar si entre 
sus vecinos existen al menos X que no pertenecen ya a un 
grupo, más un número variable Y que indica el número de 
vehículos que pueden apagarse, separarse o no unirse al nuevo 
grupo que se va a crear. En caso de que el número de vehículos 
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Fig. 2. 


Elección de Grupo 


vecinos sin grupo sea inferior al mínimo requerido para esta 
formación de grupo, el vehículo espera un periodo tiempol y 
comienza de nuevo la fase de Detección de grupo. 

Si el número de vecinos supera el umbral X+Y ', el vehículo 
comienza un proceso de creación de nuevo grupo. Para ello 
realiza un multicast hacia todos los nodos vecinos a distancia 
1 con petición de creación de grupo, los nodos que la reciben 
responden aceptando o rechazando la invitación. Si el número 
de vecinos que aceptan supera el umbral mínimo X, el nuevo 
líder de grupo enviará el mensaje que permita a dichos nodos 
reconstruir la clave secreta de grupo. En caso contrario, si 
el número de vehículos que aceptan la formación de grupo 
no supera el límite X, se incrementa el valor Y sumando 
la cantidad de vehículos que no aceptaron la invitación. 
En conclusión, en esta fase son necesarios un multicast de 
invitación a nuevo grupo, una respuesta unicast por parte de n 
usuarios y finalmente un broadcast para retransmitir el mensaje 
que permita a los nodos del grupo construir la clave secreta 
de grupo. En total 2n + 1 paquetes en caso de formación de 
grupo, y n + 2 en caso de que el proceso falle. 

La creación de grupo se inicia cuando el número de vecinos 
adecuados alcance un cierto umbral de tráfico denso, cuando el 
exceso de comunicaciones sin grupos degrada la red. Por tanto, 
los paquetes de gestión generados en esta fase no influyen 
negativamente en el funcionamiento de la red. 


D. Final de Grupo 


Una vez esté conformado el grupo, el líder debe validar 
cada cierto tiempo que el grupo sigue siendo válido, para en 
caso contrario, cambiar de líder o deshacer el grupo. La figura 
4 muestra el proceso para la salida de un nodo del grupo al 
que pertenece. Cuando dicho nodo pierde el contacto con el 
líder del grupo durante un tiempo definido, el nodo deja de 


¡inicia protocolo de 


Fig. 3. 


Creación de Grupo 


pertenecer al grupo al que pertenecía y comienza la fase de 
Detección de grupo en caso de que la densidad de nodos sea 
superior al umbral. La salida, al igual que el resto de fases de 
grupo se hacen de forma automática sin que el usuario note 
ninguna diferencia en el comportamiento del dispositivo. 


Fig. 4. Pertenencia a Grupo 


La figura 5 muestra cómo el lider del grupo comprueba 
periódicamente que el grupo sigue siendo útil. En caso de que 
el tamaño del grupo caiga por debajo de cierto umbral, el líder 
comprueba si tiene un número de vecinos mayor o igual a D 
(umbral de tráfico denso) espera un tiempo2 en vez de iniciar 
un protocolo de final de grupo para no introducir tráfico de 
gestión cuando el vehículo se encuentra en una situación de 
tráfico denso. En caso de no estar en una situación de tráfico 
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denso, el actual líder comenzará un proceso de cambio de 
líder o final de grupo. Para ello preguntará a sus vecinos la 
densidad de su vecindario y tras esto sabrá si existen vecinos 
con densidad de vecindario suficiente (con número de vecinos 
pertenecientes al mismo grupo o sin grupo asignado mayor que 
X>) y cuál de ellos tiene la mejor situación (mayor número de 
vecinos pertenecientes al grupo en su alcance de transmisión). 
Después enviará una señal multicast de cambio de líder a todos 
sus vecinos y el nuevo líder iniciará una fase de creación 
de grupo con los nodos sin grupo que están en su rango de 
transmisión. En caso de no existir ningún vecino que supere 
dicho umbral, el líder enviará mediante multicast la señal de 
final de grupo a todos sus vecinos. 

Esta fase de grupo es la que más comunicaciones requiere 
pero el número de paquetes retrasmitido no influye negati- 
vamente en la red dado que sólo se lleva a cabo cuando el 
número de nodos en el rango de transmisión no alcanza el 
umbral D de alta densidad. En esta fase se genera un paquete 
multicast de petición de potencial de cada nodo (número de 
vecinos pertenecientes al grupo más vecinos no pertenecientes 
a ningún grupo). Responderán sólo los nodos cuyo potencial 
supere el umbral de grupo X. En el peor de los casos esto 
implica n unicast hacia el líder. Finalmente se requiere un 
multicast desde el líder hacia el resto de los vecinos con la 
señal que corresponda: cambio de líder o final de grupo. Si 
es una señal de cambio de líder, el nuevo líder inicia una 
petición de creación de grupo. Por tanto en esta fase se generan 
en el peor de los casos n +1 (número de vecinos del líder) 
+m +1 (número de nodos no pertenecientes a ningún grupo 
en el alcance del nuevo líder). Obsérvese que el número de 
paquetes generados es mayor que si se disolviera el grupo y se 
volviera a crear, pero sin embargo, el coste computacional de 
construir una nueva clave secreta compartida por los vecinos 
es alto por lo que evitar tener que generar dicha clave prima 
sobre el número de paquetes generados. 


V. TRATAMIENTO DE MENSAJES EN EL GRUPO 


Tal y como se ha destacado, el número de comunicaciones 
que se producen en las VANETs en momentos de tráfico 
denso es inmenso. Por este motivo una buena gestión de 
las comunicaciones se hace necesaria en dichos casos. La 
utilización de grupos formados antes de llegar a una situación 
de tráfico denso permite gestionar las comunicaciones de 
forma eficiente enviando el menor número de paquetes posible 
sin perder ningún tipo de información útil. 

En la figura 6 se explican los pasos que un vehículo 
conectado a un grupo debe seguir para tratar una señal de 
entrada. En primer lugar debe comprobar si el paquete que le 
llega es parte de una secuencia que está reenviando. Si es así, 
debe seguir con la secuencia y reenviar el paquete hacia el 
nodo destino, y cuando se completa la secuencia se termina 
el proceso de recepción. En caso de que el paquete no sea 
parte de una secuencia, se distingue si el vehículo es el líder 
del grupo o no. En este último caso, si el dato no va dirigido 
hacia el vehículo, comprueba si el dato lo envía el líder del 
grupo. El líder de grupo envía dos tipos de paquetes a nodos 
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Fig. 5. 


Vida del Grupo 


del grupo no destinatarios:, conexión a internet para secuencia 
de información, O paquete de información pública que debe 
ser reenviado hacia otras partes de la red. 

El líder es el encargado de tratar los datos que llegan al 
grupo. Esto no significa que sea el líder el que comprueba que 
todos los datos son correctos. En su lugar, el líder gestiona la 
información que llega al grupo y reparte la comprobación de 
la información entre el resto de nodos del grupo indicando 
qué firmas debe comprobar cada uno. 

Se distinguen tres tipos de información: Información de 
seguridad vial, publicidad y conexión a internet. Tanto en 
las conexiones de seguridad vial como en las de publicidad, 
el vehículo que pertenece al grupo que recibe o produce la 
comunicación, se la envía al líder del grupo que la reenviará a 
su vez a todos los vehículos conectados del grupo y hacia 
las zonas donde el mensaje no haya sido difundido. Esta 
difusión la realizará utilizando los vehículos del grupo que 
estén mejor situados para la retransmisión o otros vehículos no 
pertenecientes al grupo que estén en el alcance de la conexión. 
En la figura 7 podemos ver una imagen que muestra las fases 
de conexión por las que pasa una conexión a internet mediante 
el reenvío de información. En este ejemplo en concreto el 
camión quiere realizar una conexión a internet, y para ello 
realiza una petición hacia un vehículo fuera de su grupo, el 
cual reenviará la petición hacia su líder. El líder enviará la 
petición hacia la RSU la cual le contestará dándole detalles 
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Fig. 6. Tratamiento de Mensajes en el Grupo 
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Fig. 7. Conexión a Internet 


de la transmisión como número de paquetes para la conexión. 
Con esta información y sabiendo la posición y velocidad de 
los vehículos del grupo y del vehículo que se quiere conectar, 
el líder realiza los cálculos que le indicarán cuánto tiempo de 
conexión existe entre la RSU, los vehículos intermedios y el 
vehículo final. Después de esto el líder balanceará la carga de 
la conexión de forma que los paquetes lleguen al destino que 
los solicitó lo mejor y más rápidamente posible. Una vez que el 
líder haya avisado a los vehículos intermedios, estos vehículos 
se conectarán con la RSU y con el vehículo conectado y 
retransmitirán la conexión. Para que este esquema funcione 
se hace necesario el uso de mecanismos de cooperación como 
los expuestos en [6], debido a que sin este tipo de mecanismos 
los vehículos intermedios no tendrán los incentivos suficientes 
para retransmitir conexiones que no son suyas, imposibilitando 
de esta manera cualquier tipo de servicio que incorpore la 
conexión con las RSU. 


VI. CONCLUSIÓN 


En este artículo se ha propuesto la utilización de grupos 
como solución para disminuir el número de comunicaciones 
que se producen en caso de tráfico denso y que provocan una 
disminución considerable en la calidad de las comunicaciones. 
Para ello se han descrito las diferentes fases del esquema 
completo para la incorporación de grupos en las VANETSs. 
Se han diferenciado los estados en los que se puede centrar 
cada vehículo, desde el estado inicial en el que no pertenece 
a ningún grupo y procede a la detección de grupo, pasando 
por la elección de algún grupo ya creado, o la creación de un 
nuevo grupo, siendo en este caso el vehículo el líder de este 
nuevo grupo. También se contempla en el trabajo cómo actuar 
frente a las conexiones entrantes, debido a que la existencia 
de grupos afectan directamente a las comunicaciones que se 
producen en este tipo de redes. 

Este trabajo está en desarrollo y en versiones futuras se 
incluirán resultados de simulación utilizando el simulador de 
tráfico SUMO y el de redes NS-2, analizando con detalle 
el funcionamiento de cada una de las fases y la reducción 
de conexiones con respecto a un mecanismo que no utilice 
grupos. Se estimarán los valores óptimos para los umbrales que 
definen cuándo merece la pena formar grupos y se analizarán 
los problemas relativos a la formación de grupos que se 
escapan utilizando modelos teóricos. 
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Resumen—La parte más compleja de un sistema de votación 
electrónica basado en el paradigma de la mezcla de votos 
corresponde a la prueba de conocimiento nulo necesaria para de- 
mostrar que el proceso de mezcla se ha realizado correctamente. 
En este trabajo estudiamos la prueba propuesta por Peng, Boyd y 
Dawson en 2005 diseñada para sistemas donde los votos se cifran 
utilizando un criptosistema de clave pública homomórfico aditivo. 
De nuestro estudio se deduce que dicha prueba también puede ser 
utilizada cuando los votos se cifran utilizando la cifra ElGamal 
en su modo habitual (homomórfico multiplicativo) reduciéndose 
significativamente el tiempo necesario para su ejecución. Las 
mismas conclusiones se pueden aplicar a la propuesta mejorada 
y corregida del sistema publicada por Peng y Bao en 2009. 


I. INTRODUCCIÓN 


Un sistema de votación electrónica remota permite a sus 
participantes ejercer el derecho a voto a través de una red 
de comunicaciones, con lo cual se elimina la necesidad de 
desplazarse físicamente al colegio electoral. Un sistema de este 
tipo debe ofrecer suficientes propiedades de seguridad para 
garantizar que la votación no pueda ser manipulada de ningún 
modo. Mediante estas propiedades se pretende que solamente 
puedan votar (una única vez) los participantes que aparecen en 
el censo, de forma secreta y con garantías de que el resultado 
del recuento sea correcto. Además, el contenido de los votos 
ha de mantenerse en secreto hasta que la votación concluya. 

Los sistemas de votación electrónica remota pueden clasi- 
ficarse en tres paradigmas: 

= Sistemas basados en firma ciega 

= Sistemas con recuento homomórfico 

= Sistemas con mezcla de votos 

En el paradigma basado en firma ciega [8], los participantes, 
en una primera fase, interactúan con una entidad de confianza 
que firma su voto de forma ciega. Posteriormente, este voto 
que ha sido firmado ciegamente es enviado al colegio electoral 
virtual a través de un canal anónimo. Al finalizar la votación, 
todos los votos serán descifrados antes de proceder a su 
recuento. Este paradigma es el más simple y eficiente desde 
el punto de vista computacional. Desafortunadamente, una 
entidad de confianza deshonesta sería capaz de enviar votos 
falsos que resultarían indistinguibles de los legítimos. Por este 
motivo, es un paradigma que resulta poco aconsejable a pesar 
de haber sido implementado en diversas plataformas [5], [9]. 

En los sistemas con recuento homomórfico [4] los par- 
ticipantes envían su voto cifrado mediante un criptosistema 


homomórfico aditivo. El colegio, una vez ha recibido todos 
los votos, los suma homomórficamente obteniendo así un 
criptograma que al descifrarse da como resultado la suma 
de todos los votos individuales. Para que un sistema de este 
tipo sea seguro es necesario que los participantes, cuando 
envían su voto cifrado, demuestren que el criptograma enviado 
contiene un voto válido. Las pruebas de conocimiento nulo 
que permiten demostrar la validez del voto cifrado [15] tienen 
un coste que aumenta mucho cuando el número de opciones 
o candidatos es grande. Por tanto, este paradigma resulta 
apropiado únicamente para votaciones simples (por ejemplo, 
votaciones de tipo “Sí”/“No”). La plataforma [1] utiliza este 
paradigma. 


El paradigma basado en la mezcla de votos [2] es el que más 
se asemeja a una votación tradicional con urna. En este caso, 
los participantes envían sus votos cifrados al colegio electoral 
virtual donde serán almacenados. Una vez se han recibido 
todos, los votos son mezclados y recifrados con el objetivo 
de que se pierda el vínculo entre voto y votante (privacidad). 
Finalmente, los criptogramas resultantes del proceso de mezcla 
son descifrados. La mezcla debe ser verificable en el sentido 
de que tiene que ser posible demostrar que durante el proceso 
de permutación y recifrado no se ha eliminado, añadido ni 
modificado ningún voto. En la literatura existen multitud de 
propuestas de sistemas que permiten verificar la corrección de 
un proceso de mezcla de votos [3], [11], [12], [16], [17], [18]. 


La gran ventaja de los sistemas basados en mezcla de votos 
es que con ellos se puede llevar a cabo cualquier tipo de 
votación siempre que un voto sea codificable mediante un 
mensaje que permita ser cifrado mediante un criptosistema 
de clave pública. Esto se debe a que después del proceso 
de mezcla todos los votos son descifrados y, en caso de 
hallarse uno con formato incorrecto (voto nulo), éste podrá ser 
descartado sin perjudicar el correcto desarrollo del proceso. De 
este modo, no es necesario que cada votante demuestre que el 
voto que ha enviado es correcto, evitando así la limitación de 
los sistemas homomórficos. 


Existen propuestas híbridas, por ejemplo [14], que con- 
siguen reducir el coste de verificar un proceso de mezcla 
aprovechando las propiedades homomórficas de un criptosis- 
tema. 
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LA. Contribución y estructura del artículo 


En [17] se presenta un sistema de votación electrónica 
basado en el paradigma de la mezcla de votos. La prueba 
allí presentada se halla descrita para votos cifrados utilizando 
el criptosistema (homomórfico aditivo) de Paillier. Los au- 
tores afirman que el sistema también puede usarse utilizando 
la cifra ElGamal en modo aditivo remarcando que la op- 
eración de descifrado requiere el cálculo de un logaritmo 
discreto (solamente aceptable cuando el espacio de textos 
en claro es reducido). En este artículo demostramos que la 
prueba [17] también puede usarse en el modo habitual de 
ElGamal (homomórfico multiplicativo). Además, se demuestra 
experimentalmente que el coste computacional de la prueba 
implementada sobre la cifra ElGamal es menor que sobre la 
cifra de Paillier. Los resultados de este trabajo son igualmente 
aplicables a la versión mejorada y corregida de dicho sistema 
presentada en [16]. 

El artículo se estructura de la siguiente forma. La primera 
sección es una introducción a la votación electrónica. En la 
sección II se describen los fundamentos criptográficos y en la 
sección III se presenta la prueba de Peng, Boyd y Dawson tal 
como se halla descrita en [17]. En la sección IV se detalla la 
prueba anterior una vez ha sido adaptada para su uso con la 
cifra ElGamal. Finalmente, la sección V está dedicada a los 
resultados experimentales. 


II. PRELIMINARES 
IFA. La cifra Paillier 


El criptosistema de Paillier [13] basa su seguridad en la 
intratabilidad del problema computacional de encontrar un 
enésimo residuo en Zy con N = p-q cuando p y q son 
números primos no conocidos. La clave privada se genera 
escogiendo dos primos p y q. La clave pública está formada 
por N = p-q y un elemento g € Zy2 cuyo orden es múltiplo 
de N. 

Un mensaje m € Z;, se cifra calculando 


m.N  (mód N?) 


c=Jg"-r 
donde r € Z%, es un valor aleatorio. 
Un criptograma c se descifra mediante la operación 


m=L(c? (mód N?))- 4 (mód N) 
donde L(u) = 4, A =mem(p=1,q=—1) y 
u=(L(g” (mód N?)))72 (méd N), 


La cifra de Paillier es un homomorfismo aditivo. Dados dos 
criptogramas cy = g” -rN y ca = g”? - rI, vemos que 
c = eica (mód N?) = gr+m . (1, - ra) (mód N?) de 
tal modo que al descifrar c obtendremos D(c) = m1 + ma 
(mód N). 

La propiedad anterior permite que, dado un criptograma c, 
tomando — al azar, obtengamos un criptograma distinto c” = 
c-rN (mód N?) tal que D(c) = D(c”). 

Tambien es fácil ver que dado un criptograma c = g” . y N 
(mód N?) y un entero k, calculando e” = c* (mód N?), se 
obtiene que D(c') =k- D(c) (mód N). 


II-B. La cifra ElGamal 


La cifra ElGamal [6] se basa en la dificultad de resolver el 
problema del logaritmo discreto planteado sobre un subgrupo 
G de orden primo q del grupo multiplicativo Z;. Dado un 
generador y de G, una clave privada se genera escogiendo un 
entero aleatorio x del intervalo [1,q — 1]. La clave pública 
correspondiente a x es y = g” (mód p). 

Dado un mensaje codificado como un elemento m € G, 
éste se cifra calculando la tupla 


(c, d) NN (9, m ? y”) 


donde r € [l,q — 1] es un valor aleatorio. A partir del 
conocimiento de la clave privada x, el texto en claro de un 
criptograma se recupera mediante la operación m = Z. 

La cifra ElGamal es un homomorfismo multiplicativo. Es 
fácil comprobar que dados dos criptogramas (c¡,d¡) = 
(g7,mi, - y) y (ca, da) = (9”2,ma - y”) que cifran los 
mensajes en claro mi y ma respectivamente, el criptograma 
(c,d) = (61 + c2,dí « da) = (971772, m1 «ma + y +12) cifra el 
mensaje my - ma. 

Esta propiedad permite transformar un texto cifrado (c, d) = 
(g”,m-y”) en un criptograma distinto (c”, d') = (c-g”",d-y”), 
con r” escogido al azar, cuyo texto en claro es el mismo que 
el de (c, d). 

Finalmente, dado un criptograma (c, d) que cifra un texto 
en claro m, el criptograma (c,k - d) cifra el texto en claro 
k-m. 


II-C. La cifra ElGamal en modo homomórfico aditivo 


La cifra ElGamal puede modificarse para que tenga la 
propiedad de ser homomórfica aditiva. Para ello, en lugar de 
cifrar un mensaje m directamente, se debe cifrar el valor g'”” 
(mód p). 

Así, dados dos criptogramas (c1,d1) = (gg - y”2) 
y [c2,da) = (g”2,g"2 - y"2), podemos operarlos y obtener 
(c, d) = (e, - Ca, d1 - da) an (ger, grama ya era), Al 
descifrar el criptograma (c,d) se obtiene h = g""**"2 de 
donde se puede recuperar my + ma resolviendo el logaritmo 
discreto mi + ma = log, h. 

Debido a que para descifrar un mensaje es necesario calcular 
un logaritmo discreto, esta variante solamente es utilizable 
cuando el espacio de textos en claro posibles es reducido. 


II-D. Mezcla verificable de votos 


En un sistema de votación electrónica basado en el paradig- 
ma de la mezcla de votos, el colegio electoral virtual recibe los 
votos cifrados de todos los participantes y genera el conjunto 
C = [c1,C2,..., Cn) donde c, es el criptograma que cifra el 
voto enviado por el 2-ésimo participante. 

En el proceso de mezcla, el colegio, a partir de una 
permutación aleatoria r de m elementos, genera un nuevo 
conjunto C* = Lc, Ca, ..., Cc), ) tal que D(c;) = D(cr(i)). Para 
garantizar la privacidad es necesario que sin conocimiento de 
la clave privada no sea posible vincular a qué voto de C 
corresponde cada voto de C”, es decir, no ha de ser posible 
estimar la permutación 7. Una vez se ha mezclado, para 
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proceder al recuento, simplemente se deben descifrar todos 
los votos de C” sin riesgo de que sea posible vincularlos con 
su origen. 

Durante este proceso, a parte de la privacidad, también es 
necesario que se garantice la integridad del proceso. El colegio, 
a parte de permutar y recifrar los votos, también tiene que 
demostrar que este proceso se ha realizado correctamente. La 
prueba de corrección debe garantizar que el conjunto C” se ha 
generado correctamente (no se ha producido la manipulación 
de ningún voto). 


TII.. EL SISTEMA DE PENG, BOYD Y DAWSON 


En [17] se presenta una prueba que permite demostrar que 
un proceso de mezcla de votos (cifrados mediante la cifra 
Paillier) se ha realizado correctamente. En esta prueba inter- 
actúan dos entidades. El probador (colegio electoral virtual) 
demuestra a un verificador (cualquier participante o supervisor 
de la elección) que el proceso de mezcla se ha realizado 
correctamente. 

En esta prueba, el conjunto de entrada C' = ([c1,...,Cn) 
está compuesto de criptogramas cifrados con la cifra de 
Paillier. Para generar el conjunto C” el probador procede como 
sigue: 

1. Escoge aleatoriamente r; € Ziy para ¿=1,...,n. 

2. Genera una permutación aleatoria r de n elementos. 

3. Calcula c, =Cr(i) «1 N (mód N?). 

4. Publica el conjunto de votos mezclados y recifrados 

C'=4c,,...,. + 

A partir de este momento, el probador y el verificador 
ejecutan un protocolo a través del cual el probador demuestra 
al verificador que el contenido (texto en claro) de los textos 
cifrados del conjunto C” coincide con el contenido de los 
de C. La prueba se basa en que, a partir de ciertos valores 
sí, s, escogidos por el verificador, el probador demuestre, en 
conocimiento nulo, que conoce unos valores secretos blas 
para ¿ =1,...,n, tales que, 


n 


Y sDle) = 2 tiD(c;) (mód N), 


Y» 5iD(ci) => D(ci) (méd N), 


¿=1 
SN sis¿D(c;) = Y tit,D(c;) (mód N), 
¿=1 i=1 


donde D(-) denota la operación de descifrado. 
A continuación se detalla el proceso para llevar a cabo la 
prueba en su forma no interactiva: 


1. El verificador publica s;,sí E [0,...,2% — 1] para ¡ = 
1,...,n (L es un parámetro de seguridad). 
2. El probador escoge aleatoriamente r/ € Zy para i = 


1,...,n y publica 


mo ti IN 
Ch =C¿ TY; 


(mód N?) 


donde t; = S7(;)- 


3. El probador calcula los siguientes valores: 


Ri=IL_.1 a (mod NL, 
=M ri (mód N7?), 
R3= HE; plat: (mód p(N)) pit (mód N?) 
y publica: 
01 = lísc2 (méd N?), 


(mód N?). 

4. El probador genera aleatoriamente W;,,W2,W3 y 
Uj, U,, E¿ E Ziy, para ¿=1,2,...,n. 

5. El probador calcula 


a=0e "<a (mód-N?), parai=L. 00. 1 
F=WN (méd N?), 


6. El probador calcula 
c= H(F, A, B,a1,42,..., Ap), 
donde H es una función hash con una salida de 128 bits. 
7. El probador calcula 
21 =W1- Ri  (mód N?), 
za = T2  (mód N?,, 
23 = A (mód AN7?), 


a=r> e [mod NE). di = Li... mí 
Yi == +C- ti (mód N), ¿=1,...,n, 
v=c:t=v, (mód N), ¿=1,...,n. 
8. El probador publica 21, Z2, 23, Q1,*** An, Y1,*** > Yn> 
/ / 
Vio: 
9. El verificador comprueba que 
N C C 
=H eE C5 C3 
OS y O O y OE 
ES VE 
Fa N Ya N 
q :0a Cn” mn 
a 


La prueba presentada permite verificar que una mezcla 
de votos cifrados con la cifra de Paillier se ha realizado 
correctamente (véase [17]). Se puede comprobar que el coste 
computacional de la prueba es lineal respecto al número de 
votos 7. 


IV. PRUEBA ADAPTADA PARA SU USO CON ELGAMAL 


En la sección anterior se ha descrito la prueba tal co- 
mo se detalla en [17]. Esa prueba requiere que los votos 
se hallen cifrados utilizando un criptosistema homomórfico 
aditivo. Puede parecer (y así se afirma en [17)), que si 
deseamos usarla con la cifra ElGamal, deberemos utilizar 
esta cifra en su modo homomórfico aditivo con lo cual, a 
la hora de descifrar cada voto será necesario resolver un 


191 


problema del logaritmo discreto. Para que este problema sea 
tratable se debe cumplir que el espacio de textos en claro sea 
pequeño. El problema es que con esta limitación se pierde 
la principal ventaja que ofrecen los sistemas de votación 
electrónica basados en la mezcla de votos frente a los sistemas 
con recuento homomórfico. 


Un análisis más detallado permite llegar a la conclusión de 
que no es así. En ElGamal aditivo, para cifrar un mensaje m;, 
primero calculamos g, = g””* y después, este valor g, se cifra 
utilizando la cifra ElGamal en su modo habitual. Al descifrar, 
primero se obtiene y, y después se calcula my = log, 91. 


Con ElGamal en modo aditivo, una prueba que demuestre 
que el conjunto de mensajes obtenido al descifrar es una 
permutación de los textos en claro M = [m1,...,mn) que 
se han recibido cifrados también demuestra que los valores 
obtenidos antes de resolver el logaritmo discreto son una 


permutación de (g"2,...,g”"»). 


Así pues, para utilizar la prueba [17] en un criptosistema 
homomórfico multiplicativo, lo único que se debe hacer es 
cifrar los votos utilizando el modo multiplicativo normal y 
después implementar la prueba como si la cifra se estuviese 
utilizando en modo aditivo. 


A continuación se detalla como utilizar la prueba [17] 
teniendo en cuenta el razonamiento anterior cuando los votos 
se hallan cifrados con ElGamal en modo multiplicativo. 


Ahora, el conjunto de votos recibidos está formado por crip- 
togramas de la cifra ElGamal C = [(c1,d1),..., (Cn, dn)). 


La mezcla y recifrado de votos se realiza de la siguiente 
forma: 


1. El probador escoge aleatoriamente r, € Z¿ para i = 
A 

2. Genera una permutación rm de n elementos. 

3. Calcula (c;,d¿) = (Cr(s) * 9, dm(s) y") para ¿ = 
Mia 70 

4. Publica el conjunto de votos mezclados y recifrados 


CO" =[(01,d1),-.-, (Cp, dy) y. 


A continuación detallamos como realizar la prueba de [17] 
cuando los votos están cifrados utilizando ElGamal: 


1. El verificador publica s;,s/ E [O,...,2% — 1], para i = 
1,2,...,n (L es un parámetro de seguridad). 

2. El probador escoge aleatoriamente rí € Zy, para i = 
1,...,n, y publica (c/, d/) = (c/* - g"+, d/* .y"+) donde 
t; = Sri)" 


3. El probador calcula: 


Ri =D ¡1 (ri ti +15) (mód g), 
Ra = ¡11 t (mód q), 


Ra =Ni 1 ti ti +ri-t, (mód q), 


y publica: 
C1 = HZ (mód p), 
i=1%, 
Ca =[[-1 07" | (mód p), 
n Sis! mód ó 
Cs =Il;=1 Cc de dl (mód p), 
D; = Liz (mód p), 
ií=1 4 ñ 
Dz=1TÍ;21dj'  (mód p), 
RM" di (mód p). 


4. El probador genera aleatoriamente W,,W2,W3 y 
UV, U,, ¿E Ly, parai=1,...,n. 
5. El probador calcula 


as =c - g%  (mód p) parai=1,...,n, 
b¡ =dj"* - y?  (mód p) parai=1,...,n, 
F,=ygW:  (mód p), 

F¿=yW  (mód p), 

A. = lMispz— (méd p), 

Ay = Sp iZ (mód p), 

B.= — - p (mód p), 


Ba= Hip di * (mód p). 
6. El probador calcula 
c= H(P., Fa, Ac, Aa, Be, Ba, a1, ba, Pe Un» Bn), 


donde H es una función hash con salida de 128 bits. 
7. El probador calcula 


21 =W1¡ +R1-c- (mód q), 
zo = W2¿— R2-c  (mód q), 
z3 = W3—R3-c (mód g), 
as =x,+1¡.c (mód q), ¿=1,...,n, 
Yi = +C- ti (mód q), ¿=1,...,n, 
Y =c:t,—v, (mód q), ¿=1,...,n. 


8. El probador publica 21, Za, 23, QU1,..., An, Yl>---> Yn> 
Vo c++ Ya 
9. El verificador comprueba: 
ey (E Y C3 2 
CD? e. .T1P ¿0? pza TIP dao 
1 “1 g%-][,_,c,* y%-]L;-, 4, 


Cc e 
CS Ds 
23 TI" OS e my? 
ge M£ 0" ye Tod 
11 01 / Q 1 Q 
di -Y con. g n dry -) 
te AS > e 
d/ de 


V. RESULTADOS EXPERIMENTALES 


Ie 3 
que 


n 


La prueba [17] ha sido implementada en Java [7] para votos 
cifrados con la cifra de Paillier (descrita en la sección III) y 
para votos cifrados con ElGamal multiplicativo (descrita en la 
sección IV). Se han realizado diferentes experimentos variando 
el nivel de seguridad y el número de votos. Para tener un 
mismo nivel de seguridad en las dos cifras se debe escoger el 
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número N = p» q de Paillier y el módulo p de ElGamal de 
igual longitud. 


Tiempo (s) 
Votos | Paillier | ElGamal 
600 16033 6017 
1000 30915 11817 
1400 96509 36636 
1800 | 136378 51070 
Cuadro I 


TIEMPO EN SEGUNDOS NECESARIO PARA PROBAR LA CORRECCION DE 
UNA MEZCLA DE VOTOS USANDO CLAVE DE 256 BITS. 


A partir del cuadro I (donde se han usado claves de 256 
bits), se puede comprobar que el tiempo de ejecución aumenta 
linealmente con el número de votos tanto si se cifra con Paillier 
como ElGamal. La relación de tiempos entre las dos cifras 
muestra que la prueba, cuando se trabaja con ElGamal, es 
aproximadamente tres veces más rápida que con Paillier. 


Tiempo (s) 
Votos Paillier | ElGamal 
600 79625 17705 
1000 | 145136 31862 
1400 | 447886 95779 
1800 | 641608 131665 
Cuadro II 


TIEMPO EN SEGUNDOS NECESARIO PARA PROBAR LA CORRECCION DE 
UNA MEZCLA DE VOTOS USANDO CLAVE DE 512 BITS. 


El cuadro II muestra el mismo experimento utilizando 
claves de 512 bits. Con esta longitud de clave, la prueba 
implementada sobre la cifra ElGamal resulta ser cinco veces 
más rápida. Finalmente, el cuadro III resume los resultados 
con claves de 1024 bits. En este caso la prueba con ElGamal 
resulta ser unas nueve veces más rápida. 


| Tiempo (s) 
Votos Paillier ElGamal 

| 

| 600 463904 58090 

| 1000 820066 99728 

| 1400 | 1211291 143156 

| 1800 | 1639864 186634 

Cuadro III 


TIEMPO EN SEGUNDOS NECESARIO PARA PROBAR LA CORRECCION DE 
UNA MEZCLA DE VOTOS USANDO CLAVE DE 1024 BITS. 


A partir de los resultados experimentales se observa que la 
prueba implementada sobre la cifra ElGamal es considerable- 
mente más rápida que cuando se implementa sobre Paillier. 
La diferencia en el tiempo de ejecución aumenta a medida 
que elevamos el nivel de seguridad. El motivo es que aunque 
los criptogramas de la cifra ElGamal están formados por dos 
componentes, en el momento de operar sobre ellos se realizan 
operaciones sobre Z, mientras que con Paillier se trabaja en 
Z,y2, siendo p y N números de la misma longitud (con lo cual 
la longitud de NV? dobla la de p). 


El proceso de adaptación que se ha presentado en este 
trabajo puede aplicarse de forma análoga a la versión corregida 
y mejorada del sistema presentada en [16]. 
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Resumen—Las elecciones son una parte muy importante de 
una democracia. Mediante éstas, la sociedad puede elegir a 
sus representantes, tomar una decisión o expresar una opinión. 
Alguien podría estar interesado en manipular los resultados de 
dichas elecciones sin ser descubierto. Por este motivo es necesario 
un control del proceso de votación que detecte y evite cualquier 
tipo de alteración. En este trabajo se estudian los principales 
sistemas de verificación (académicos y comerciales), que realizan 
dicho control en los sistemas de votación electrónica presencial. 
Con este fin se ha diseñado un marco comparativo común con el 
que se analizan todos los sistemas de verificación de votación elec- 
trónica. Este marco comparativo agrupa diferentes propiedades, 
cubriendo importantes áreas tales como la interacción con el 
usuario o la seguridad. 


I. INTRODUCCIÓN 


Un proceso electoral consiste en elegir a una persona o 
partido, es decir, un representante de todos los miembros de 
una comunidad (p.e., una empresa, un estado o un país). Para 
un candidato esto supone una gran responsabilidad pero a la 
vez un gran poder (p.e., fondos, capacidad de cambiar leyes). 

Por este motivo, existe la necesidad de comprobar la correc- 
ción del proceso de votación y de los resultados, asegurando 
así que los votos corresponden a las intenciones reales de los 
votantes. Puesto que debe mantenerse el secreto de voto y el 
anonimato del votante en todo momento, la verificación puede 
resultar difícil. A pesar de esto, cualquier sistema de votación 
debe proporcionar algún tipo de verificación. 

Los sistemas de votación tradicionales usan papeletas elec- 
torales de papel como soporte para emitir el voto. Actual- 
mente las nuevas tecnologías han propiciado la aparición 
de los sistemas de votación electrónica o “e-voting”, que 
usan dispositivos electrónicos. Estos sistemas proporcionan 
ventajas respecto a los sistemas convencionales como una 
aceleración del proceso de escrutinio o un ahorro de papel 
con consecuencias económicas, logísticas y ecológicas. Las 
primeras iniciativas fueron en EE.UU., en 1964, donde se uti- 
lizaron tarjetas perforadas y máquinas de recuento, aunque más 
recientemente se han utilizado escáneres ópticos y técnicas 
criptográficas. 

La aparición de estos nuevos sistemas ha hecho replantear 
un conjunto de problemáticas, ya conocidas en los sistemas 
antiguos, para solucionarlas y mejorarlas. Estas viejas prob- 
lemáticas derivan de la seguridad, como es el caso del secreto 
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de voto o el anonimato del votante. Éstas afectan directamente 
el proceso de verificación. Para ello se definen tres tipos de 
verificación: individual, universal y extremo-a-extremo (del 
inglés “end-to-end”). El primer tipo, definido desde el punto 
de vista del votante, permite que éste pueda comprobar que 
su voto ha sido emitido y contabilizado correctamente. La 
verificación universal permite comprobar que los votos de 
las urnas no han sido manipulados y que se han escrutado 
correctamente. Su objetivo es el de garantizar que el proceso 
que va desde la emisión del voto hasta el recuento se haya real- 
izado correctamente. En los sistemas tradicionales (basados en 
papeletas en papel y procesos manuales), se realizan ambos 
tipos de verificación por medio de un conjunto de procesos 
manuales. En cambio, para realizar dichas verificaciones en 
sistemas de e-voting es necesaria una combinación de nuevas 
tecnologías y nuevos procesos. La verificación extremo-a- 
extremo es un tipo de verificación individual que permite com- 
probar que el voto ha sido emitido y contado correctamente en 
cualquier momento de la votación. Su objetivo es el de aumen- 
tar la confianza del votante en el sistema y, consecuentemente, 
en la veracidad e integridad de los resultados electorales. Los 
nuevos sistemas de votación, a diferencia de los tradicionales, 
facilitan este tipo de verificación. 

Este estudio presenta un análisis de los sistemas de verifi- 
cación de votaciones electrónicas (SVV de ahora en adelante) 
y muestra como éstos consiguen alguno de los tres tipos de 
verificación antes descritos. En particular, se centra el enfoque 
en los SVVs del tipo presencial, en inglés “poll site”, ya 
que éstos son los más comunes actualmente. No obstante, 
en los siguientes capítulos, se verá la evolución que sufren 
los SVVs presenciales hacia el modelo remoto, adoptando 
modelos intermedios como el presencial-remoto. En este tipo 
de sistemas, el voto se emite de forma controlada, como en 
los presenciales, aunque el escrutinio se realiza remotamente, 
como en el tipo remoto (es decir, en un centro o sitio distinto 
al de la emisión). Los sistemas incluidos en este trabajo son 
los más relevantes del mundo comercial y académico de la 
última década. Por lo tanto, la contribución de este trabajo es 
doble: (1) la definición de un marco de evaluación común para 
una justa comparación de todos los sistemas y, (11) el estudio 
y comparación de los sistemas de votación electrónica más 
importantes. 


Estructura del documento. La siguiente sección introduce 
los conocimientos necesarios y las bases para entender el 
estudio. La Sección 3 presenta el marco de evaluación y la 
Sección 4 el análisis de todos los sistemas de verificación de 
votación (SVVs) incluidos. La Sección 5 analiza globalmente 
todos los sistemas, y por último, la Sección 6 presenta las 
conclusiones finales de este trabajo. 


TI. CONOCIMIENTOS PREVIOS 


En este estudio se considera que el proceso de votación 
estándar está compuesto por tres fases: (i) el registro del 
votante y su identificación, (11) la emisión de voto y (111) el 
escrutinio de votos, donde todos los votos son contabilizados 
de manera segura y los resultados son imparciales y públicos. 
El proceso de votación incluye todos los procedimientos y 
tecnologías necesarios para confiar en la votación. 


Il-A. Tipos de Votación 


A continuación se presenta la clasificación de los sistemas 
de votación según el lugar donde el votante emite el voto 
(Sección IHL-Al) y la clasificación que realiza la legislación 
de EE.UU. llamada “HAVA classification”(Sección HM-A2) 
sobre los sistemas de verificación de votaciones (SVVs). Esta 
última se utilizará más adelante para organizar los sistemas de 
votación analizados. 

Il-Al. Clasificación según el entorno: Según el sitio de 
votación y su entorno inmediato, donde el votante puede 
ejercer su voto, los sistemas de votación se pueden clasificar 
en sistemas presenciales y remotos. Para emitir un voto en 
el primer tipo, los votantes tienen que ir a un sitio dedicado 
a este propósito (p.e., colegio electoral) y con algún tipo de 
control físico (entorno controlado). En los sistemas remotos, 
los votantes pueden votar desde un sitio lejano al sitio donde 
se efectúa el escrutinio. Los ejemplos más importantes son el 
voto postal y el voto por Internet. 

Recientemente se ha propuesto un nuevo tipo de sistemas 
que pretende aprovechar las ventajas tanto de los sistemas 
presenciales como de los remotos; el presencial remoto. Este 
tipo de sistemas permiten emitir el voto en un entorno con- 
trolado, aunque su escrutinio se realiza en otro sitio destinado 
específicamente al recuento seguro y centralizado de todos los 
votos. 

II-A2. Clasificación HAVA: Esta clasificación fue pro- 
movida por la Election Assistance Commission (EAC), una 
agencia independiente del Gobierno de EE.UU. creada por 
Help America Vote Act 2002 (HAVA). La agencia EAC 
definió las Voluntary Voting System Guidelines (VVSG) en 
2005 [1], que consistían en unas directrices que clasifican los 
SVVs en cuatro tipos: (i) los SVVs basados en separación 
de procesos tienen una arquitectura modular que separa el 
sistema en dos procesos diferentes, la generación del voto, y su 
emisión; (11) los SVVs basados en evidencias registran todas 
las acciones realizadas por los votantes durante la emisión del 
voto; (111) los SVVs directos o de verificación directa generan 
un registro paralelo al del voto que permite la verificación 
directa del votante, es decir, que el votante no requiera de 
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ninguna tecnología para interpretar el contenido del registro; 
finalmente, (iv) los SVVs basados en criptografía extremo 
a extremo usan métodos criptográficos para la construcción 
de recibos. Éstos permiten a los votantes verificar, sin com- 
prometer su privacidad, que su voto no ha sido modificado. 


III. MARCO DE EVALUACIÓN COMÚN 


Esta sección establece la clasificación que se utilizará para 
organizar los sistemas de verificación a estudiar y también 
define y clasifica las propiedades de éstos. Todo ello constituye 
el marco común que se usará más adelante para analizar y 
comparar los SVVs. 


IIFA. Clasificación de los SVVs 


En esta sección se presentan los criterios la clasificación 
de los SVVs. El año de su primera publicación es la última 
propiedad usada para organizarlos. 


1. Entre los sistemas electrónicos y los basados en papel, 
sólo se consideran los electrónicos. Éstos requieren que 
el voto esté en formato electrónico en vez de papel. 

2. Se usa la clasificación HAVA antes mencionada para 
diferenciar los SVVs en sistemas basados en separación 
de procesos, en evidencias, en criptografía extremo a 
extremo (E2E) y directos. 

3. Se distingue entre sistemas integrales e independientes. 
Los primeros son sistemas completos que realizan todo 
el proceso de votación, incluido el de verificación. En 
cambio, los independientes están diseñados únicamente 
para verificar la votación sin estar supeditados a un 
sistema de votación determinado. 


HIFB. Propiedades Evaluadas de los SVVs 


A continuación se presentan las características consideradas 
importantes para evaluar los sistemas de verificación. Su 
clasificación obedece a los aspectos del proceso de votación 
al que conciernen: interacción con el usuario, seguridad, in- 
tegrabilidad (con un sistema de votación existente) y aspectos 
técnicos. 

Interacción con el usuario. La interacción con el votante 
determina en gran medida la impresión y la confianza que da 
el sistema: 


1. Accesibilidad. Facilidad de uso del sistema (p.e., usuar- 
los con algún tipo de discapacidad). 

2. Impacto de uso. Complejidad del proceso de emisión 
de voto comparado con el proceso habitual. 

3. Confiabilidad. Confianza en el proceso de votación 
desde el punto de vista de los votantes. 


Seguridad. Las propiedades de seguridad están relacionadas 
con el votante y con el proceso de votación: 
Relacionados con el votante: 


4. Secreto de voto. El sistema impide que una tercera 
persona conozca el contenido del voto. 

5. Anonimato. El sistema impide que se mantenga 
cualquier relación entre el voto y el votante. 


6. Resistencia a la coacción. El sistema impide que el 
votante pueda probar a una tercera persona el contenido 
de su voto. 

7. Verificación individual. El sistema permite que el 
votante pueda comprobar que su voto se ha contabilizado 
correctamente. 


Relacionados con el proceso de votación: 
= Verificación universal. Ésta se descompone en: 


8. Integridad de la urna. Únicamente los votos de 
votantes autorizados pueden estar en la urna de 
manera inalterada hasta el final del proceso de 
votación (antes del escrutinio). 

9. Precisión del escrutinio. El escrutinio debe contar 
todos los votos emitidos de manera correcta no 
antes del final de la votación. 


10. Auditabilidad. El sistema de votación electrónica per- 
mite a una tercera persona, sin comprometer otras 
propiedades de seguridad, analizar lo sucedido en las 
elecciones. 


Integración. El SVV, sea integral o independiente, tiene la 
posibilidad y la efectividad de adaptarse/integrarse con otros 
sistemas de votación, actuando el SVV de forma independiente 
(de la misma forma que se realizó en [2]). Se tiene en cuenta 
la sincronización de las operaciones, especialmente la emisión 
de votos, entre el sistema de votación y el SVV. 


11. Integración. Facilidad de implementación/adaptación 
del sistema evaluado como sistema verificador indepen- 
diente de otras infraestructuras de votación. 

Gestión de la información. Evalúa cuando el subsis- 
tema de emisión de votos de los sistemas de votación 
y el sistema evaluado garantizan tanto atomicidad de 
Operaciones, como resistencia a fallos (p.e., errores de 
usuarios, desconexiones de cables). 


12. 


Aspectos técnicos. Se analiza el rendimiento de los SVVs 
desde un punto de vista técnico: 


13. Simplicidad. Cuando el SVV es directo y sencillo. 

14. Disponibilidad. El votante debe poder emitir su voto 
sólo cuando se le permita, durante el tiempo establecido 
para ello, y previniendo que pueda emitir más de un voto 
(si no está permitido). 

Escalabilidad. El sistema verificador escala computa- 
cionalmente. 

Flexibilidad. Esta propiedad evalúa el nivel de libertad 
que ofrece el sistema verificador (p.e., número de can- 
didatos, modo escritura —“write-in”). 


15: 


16. 


Representación. Por simplicidad, a continuación se muestra 
la notación usada en cada una de las 16 propiedades evaluadas 
en los sistemas estudiados. 


IV. ESTUDIO Y COMPARACIÓN DE LOS SVVs 


En esta sección se presentan los SVVs (Sección IV-A), su 
análisis (Sección IV-B) y el estudio de las sinergias entre los 
sistemas de votación electrónica y las técnicas criptográficas 
(Sección IV-C). 
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Cuadro I 
LISTA DE VALORES DE LAS PROPIEDADES EVALUADAS. 


Interacción 


con él Úsuañió + /J / -: Buena/Débil/Aceptable. 


Seguridad S/N/=: Sí/No/Parcialmente. 
NT: No existen requisitos Técnicos adicionales (en termi- 
nales de votación, etc.). 
sb T: Existen requisitos Técnicos adicionales. 
Integración 


NSW: No existen requisitos SoftWare adicionales (en 
terminales de votación, etc.). 
SW: Existen requisitos SoftWare adicionales. 


NA: No existe Atomicidad en las operaciones. 


Gestión de la A: Existe Atomicidad en las operaciones. 


información PD: Existe Pérdida de Datos. 
NPD: No existe Pérdida de Datos. 

Apodos + / y: Propiedad Alta/Baja 

Técnicos a i 


En cualquier 


Pasa “N/A”: La propiedad no fue considerada por el sistema. 


IV-A. Presentación y Clasificación de los SVVs 


Por razones de espacio, a continuación se listan brevemente 
los sistemas de mayor relevancia, y que han estado incluidos 
en el presente estudio. Para mayor detalle, se invita al lector 
a visitar las referencias externas indicadas. 

Siguiendo la categorización HAVA, en el conjunto de SVVs 
basados en separación de procesos se incluye Modular 
Voting Architecture (“Frog”) [3]. En la categoría de SVVs 
basados en evidencias se han estudiado VWVAATT [4] y 
VVVAT [5]. Finalmente, en el grupo de SVVs basados en 
criptografía extremo a extremo se han analizado VoteHere 
[6], VoteBox [7], Three-Ballot [8] y E-valg [9]. 


IV-B. Análisis y Evaluación de los SVVs 


Para analizar y valorar los SVVs se siguen las propiedades 
antes descritas en el marco común de evaluación. En la Cuadro 
III se puede ver el resumen de este análisis. 


Interacción con el usuario. Dado que todos los SVVs usan 
DRESs (del inglés “direct recording electronic voting termi- 
nals”) para emitir los votos, todos ellos tienen un cierto grado 
de accesibilidad. No obstante, algunos lo mejoran usando 
audioguías (VVAATT) o añadiendo otras tecnologías asistivas 
(como el ratón o el teclado) (VoteBox y E-valg). En el caso 
del E-valg, esto ya fue probado en los estudios [2], [10]. En 
cuanto al impacto de uso, sistemas como Frog, VoteBox y 
Three-Ballot presentan mayor complejidad y un proceso de 
votación ligeramente más largo. Por ejemplo, en el Frog existe 
una separación estricta entre los procesos de generación y 
emisión de voto (a pesar de que un votante pueda traer la 
papeleta llena de casa); VoteBox permite a los votantes realizar 
un “immediate ballot challenge” [11], que es una manera 
de alertar del mal funcionamiento del equipo de emisión e 
inutilizar el terminal de votación; o Three-Ballot que usa una 
multi-papeleta compuesta por tres partes. Además, todos ellos 
incorporan tres técnicas distintas con el fin de incrementar la 
confianza en el sistema: (i) frogs (Frog) y recibos (VoteHere, 
VoteBox, Three-Ballot y E-valg) son elementos tangibles para 


el votante, (11) audio guías (VVAATT), y boletines publicados 
en Internet (excepto VVAATT). 


Seguridad. VVAATT/VVVAT no garantizan la confidenciali- 
dad de voto, dado que todas las grabaciones (audio o vídeo) 
muestran el orden secuencial de votación. Además, el equipo 
de grabación del VVAATT/VVVAT tiene una protección muy 
débil (ya que se accede a menudo) y unas técnicas de extrac- 
ción de información de los registros de grabación poco fiables 
y lentas. A pesar que este sistema no garantiza el anonimato 
del votante y no es fiable en su conjunto, se ha incluido en 
el estudio por ser el referente de los sistemas basados en 
evidencias. A continuación se analizan el resto de sistemas. 

Seguridad relacionada con el votante. A excepción de 
Frog, todos los sistemas usan una infraestructura de clave 
pública (PKT), la mayoría de ellos ElGamal, para garantizar 
el secreto de voto. Sin embargo, los SVVs usan técnicas 
muy diferentes para proteger el anonimato del votante. 
Mientras que Frog utiliza un simple algoritmo aleatorio, Three- 
Ballot separa cada una de las tres partes del voto y las 
almacena usando sus valores hash. También aparecen técnicas 
más complejas: mixing (VoteHere), criptografía homomórfica 
aditiva (VoteBox) o un esquema híbrido (E-valg), que combina 
criptografía homomórfica multiplicativa con mixing. El uso de 
esquemas umbral, extendido en gran parte de estos sistemas, 
previene ataques de seguridad procedentes de partes teóri- 
camente confiables. Por otro lado, los sistemas que utilizan 
recibos pueden permitir la coacción y la venta de votos, 
ya que pueden reflejar la opción de voto en el resguardo. 
Para solucionar esta problemática se usan los códigos de 
retorno que impiden adivinar el voto; es el caso de VoteBox, 
Three-Ballot, E-valg y VoteHere. Sin embargo, este último 
puede tener un defecto, ya que el votante podría evidenciar 
su intención de voto dado que dispone del voto cifrado junto 
con los códigos de retorno [12]. Frog, a pesar de no utilizar 
recibos, tampoco cumple con dichas propiedades, ya que no 
asegura el secreto de voto. Además, los sistemas que usan 
recibos mejoran la verificación individual a E2£. 

Seguridad relacionada con el sistema. A excepción de 
Frog, todos los sistemas garantizan la integridad de la urna 
mediante diferentes tecnologías (como pruebas de conocimien- 
to nulo —ZKPs—, firmas digitales o esquemas umbral). Ver 
el Cuadro II para mayor detalle. VoteHere, VoteBox, Three- 
Ballot y E-valg avalan la precisión del escrutinio. Los 
sistemas homomórficos hacen un recuento más eficiente que 
las técnicas de mixing [13], [14]. En cuanto a la auditabil- 
idad, Three-Ballot crea unos registros o pistas de auditoría 
para cualquier operación relacionada con los votantes, aunque 
ninguna sobre el proceso de recuento. Los sistemas evaluados 
que ofrecen más prestaciones en éste ámbito son VoteBox y 
E-valg, ya que usan trazas inmutables. VoteBox construye un 
sistema de auditoría totalmente distribuido, mientras que E- 
valg sólo audita los elementos críticos del sistema. 


Integración. En general todos los SVVs evaluados tienen 
alguna dependencia, ya sea de software o hardware (ver 
Cuadro III para más detalles), para integrarlos en los DREs. 


198 


Cuadro II 
TÉCNICAS DE SEGURIDAD USADAS POR LOS SVVs 


Técnicas de Seguridad 
Firma Esquema 
Umbral 


Sistema 
Auditoría 


Frog 
VoteHere 
VoteBox 
Three-Ballot 


Los únicos sistemas que implementan algún tipo de gestión 
de datos son VoteBox y E-valg [2], ya que garantizan la 
atomicidad del voto, son resistentes a pérdidas, y manipulación 
de datos. 


Aspectos técnicos. VoteBox y Frog son más complejos que el 
resto de sistemas estudiados, puesto que tienen una estructura 
distribuida —el último debido a la separación de procesos. Sin 
embargo, VoteBox es el único que estructuralmente propor- 
ciona replicación de la información sensible, susceptible de 
ser objeto de algún tipo de ataque. Esta característica otorga al 
sistema un alto grado de disponibilidad. Otra buena propiedad 
de VoteBox es su escalabilidad (debida a su arquitectura), 
además de un escrutinio rápido de votos (como consecuencia 
del uso de criptografía homomórfica). VoteBox y E-valg 
comparten esta propiedad. A pesar de ello, ambos deben 
abordar el voto presencial remoto con cautela, garantizando 
la infraestructura necesaria a fin de no sobrecargar el sistema. 
Finalmente, sólo Frog, VoteHere y E-valg dan flexibilidad al 
tipo votación y al formato del voto. Por el contrario, VoteBox, 
que usa las propiedades homomórficas aditivas de ElGamal, 
no soporta tipos de elecciones muy complejas. Three-Ballot 
sólo es adecuado para papeletas formadas por tres partes, a 
pesar de que el contenido de la papeleta es flexible. 


IV-C. Estudio de Tendencias en SVVs 


Del análisis anterior se extraen tres tendencias claras rel- 
ativas a los siguientes aspectos: (i) ámbito de votación, (11) 
tecnología de la votación y (ii) grado de verificabilidad. 
Estudio del ámbito de votación. En este estudio se ha 
analizado SVVs presenciales, y todos ellos usan DREs como 
terminales de votación. Claramente, los DRESs resultan de gran 
utilidad, puesto que permiten la gestión electrónica de los 
votos. En este sentido cabe destacar la tendencia existente 
de migración de sistemas electorales presenciales a presen- 
ciales remotos. Dicha tendencia es consecuencia no sólo de 
la tecnología, sino también de la evolución natural de las 
reglas democráticas. A pesar de ello, mientras que VoteBox se 
adaptó para soportar esquemas de voto presenciales remotos, 
E-valg fue estructuralmente diseñado para tal propósito. 


Estudio de la tecnología de votación. En este caso se 
considera la tecnología de votación usada desde la emisión 
de los votos hasta su escrutinio, por lo que los sistemas 
VVAATT/VVVAT no se incluyen en este estudio. El objetivo 
de estas tecnologías es el de proveer seguridad (tales como 
anonimato, integridad de la urna o precisión del escrutinio). La 
tendencia que presentan estas soluciones, de las más simples 


a las más complejas y fiables, es tal como sigue. Mientras que 
Frog usa meros algoritmos aleatorios en el tratamiento de los 
votos para garantizar el anonimato de los votantes, VoteHere 
usa técnicas de mixing más fiables. VoteBox y Three-Ballot 
usan criptografía homomórfica aditiva (que es computacional- 
mente intensiva) para garantizar el anonimato, a la par que 
facilitan el escrutinio. La tecnología más compleja, pero más 
flexible y fiable, es la usada por E-valg: el esquema híbrido. 
Dicho esquema se compone de criptografía homomórfica 
multiplicativa (menos intensiva computacionalmente que la 
aditiva [13], [14]) y mecanismos de mixing. Claramente, estas 
tecnologías de votación llegan a un compromiso entre (1) 
garantizar que sean más seguras y fiables, y (ii) asegurar 
que sean rápidas y eficientes en el uso de recursos. Es claro 
que esta tendencia desde simples técnicas de aleatoriedad a 
esquemas híbrido es una consecuencia directa de la continua 
permeabilidad de los sistemas de votación con respecto a los 
últimos avances criptográficos. 


Estudio de la verificabilidad. Los sistemas analiza- 
dos se organizan como sigue. (1) Sistemas basados en 
VVAATT/VVVAT y Frog proveen una verificabilidad defi- 
ciente y básica respectivamente de los procesos de votación. 
Principalmente se centran en garantizar únicamente un cierto 
grado de verificación individual y desatendiendo la universal 
y la E2E. (11) VoteHere y Three-Ballot ofrecen un grado 
aceptable de verificabilidad (individual, universal y E2E). 
Finalmente, (111) E-valg y VoteBox aseguran un buen nivel de 
verificabilidad, a la vez que definen un sistema de auditoría 
robusto. 

En conclusión, VoteBox y E-valg son las mejores alter- 
nativas estudiadas como sistemas de votación. No obstante, 
E-valg ofrece unas características que lo hacen atractivo. La 
razón de ello es porque E-valg provee aplicaciones comerciales 
usadas alrededor del mundo, un alto grado de verificabilidad 
y una suave transición de sistemas de votación tradicionales a 
electrónicos, y mejorando así su accesibilidad y facilidad de 
uso. 


V. CONCLUSIONES 


En este trabajo se ha definido un marco de evaluación, 
común para todos los sistemas de verificación de votación 
electrónica (SVVs), y se ha elaborado un estudio comparativo 
de una selección de dichos sistemas. Para ello se han seguido 
los siguientes pasos: (i) se ha definido una clasificación de 
SVVs, (11) se han definido las propiedades a estudiar de los 
SVVs, (111) se han elegido y analizado un conjunto represen- 
tativo de SVVs tanto del mundo académico como comercial, 
y finalmente, (iv) se ha hecho un estudio de tendencias. 

La clasificación de los SVVs se ha hecho combinando varios 
criterios con el propósito de conseguir una agrupación natural 
y completa adecuada a nuestro enfoque. No se consideran los 
sistemas de votación basados en papel. Se usa la clasificación 
HAVA [1] de EE.UU., que agrupa los SVVs en función del 
tipo de verificación. Se distingue también si el método de 
verificación es independiente del sistema de votación o si ha 
sido desarrollado para un sistema concreto de votación. A 
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Cuadro TI 
DETALLE DE LAS PROPIEDADES DE LOS SVVs. 


Flexibilidad < >< > > E 
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2 ES 3 283 
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pesar de que existen muchas categorizaciones correctas, ésta 
ha sido la más adecuada para nuestros propósitos. 

Las propiedades elegidas para evaluar los SVVs han sido la 
seguridad del sistema, la confianza del votante, y en menor 
medida la flexibilidad de voto. Aspectos como el secreto 
de voto, el anonimato del votante y la precisión de los 
resultados son sumamente importantes e imprescindibles en 
unas votaciones. No es menos importante la confianza que 
deben tener los votantes en el sistema de votación. En una 
democracia hace falta confiar en ella y en los mecanismos 
que la sustentan. 

Este estudio se ha centrado en sistemas de verificación de 
elecciones electrónicas. Más concretamente, en los SVVs sin 
dependencia del papel, dado que los sistemas de votación han 


evolucionado progresivamente hacia el uso de la tecnología 
digital y la criptografía. Teniendo en cuenta este subconjunto, 
se han elegido los sistemas más relevantes. 

A partir de este estudio se puede concluir que los SVVs pre- 
tenden facilitar el voto a personas sordas mediante audio guías, 
así como aumentar la seguridad y la confianza del votante en 
el sistema. Estas últimas con la ayuda técnicas criptográficas, 
como son (i) el cifrado del voto, (11) la firma digital y el 
esquema umbral, (111) el mixing o los homomorfismos, (1v) las 
ZKPs, (v) los códigos de retorno y recibos, y (vi) la auditoría 
del sistema. 

El cifrado del voto mediante RSA o ElGamal garantiza el 
secreto de voto. Con la firma digital y el esquema umbral 
se protege la autenticidad de los votos y se aumenta el 
secreto de voto. El mixing o las propiedades homomórficas 
derivadas de ElGamal sirven para conseguir el anonimato del 
votante. Este último tiene importantes consecuencias en el 
sistema, ya que aumenta la eficiencia del escrutinio [13], [14] 
y reduce la flexibilidad tanto en el tipo como en el formato del 
voto. En cambio, el uso del mixing proporciona un escrutinio 
ligeramente más lento [13], [14]. Ambas técnicas tienen sus 
ventajas y sus inconvenientes, pero las dos necesitan del uso 
de ZKPs para conseguir una verificación universal (también 
el anonimato en los que utilizan mixing). La gran mayoría de 
SVVs utilizan códigos de retorno y recibos para conseguir una 
verificación individual (E2E), evitar la coacción del votante y 
a su vez, aumentar la confianza del votante en el sistema. 
En la actualidad existe la tendencia de auditar, cada vez más, 
los sistemas informáticos de cualquier tipo por motivos de 
seguridad. Sólo los SVVs más modernos auditan todo lo 
sucedido a lo largo del proceso electoral. 

Se puede observar cierta evolución en el uso del mixing 
y/o de homomorfismos. Los primeros sistemas homomórficos 
utilizaban las propiedades aditivas. En cambio, sistemas más 
contemporáneos emplean sus propiedades multiplicativas con 
el objetivo de aumentar la flexibilidad del voto. Otros sistemas 
llamados híbridos, aún más recientes, van más allá y combinan 
el mixing con la criptografía homomórfica multiplicativa para 
aprovechar las ventajas de ambos, y ganar en eficiencia y 
flexibilidad. 

Los sistemas de votación electrónica actuales, como E-valg 
y VoteBox, hacen posible el voto presencial remoto. Esta 
posibilidad supone un nuevo paso hacia el voto plenamente 
remoto. De hecho, ya se han realizado experiencias de voto 
por Internet. Se argumenta que la implantación de los sistemas 
remotos facilitaría la realización de consultas, aumentando la 
participación ciudadana en la toma de decisiones. Por con- 
siguiente acercaría un poco más la democracia a la sociedad. 
No obstante, la aceptación de estos esquemas dependerá del 
cumplimiento al mismo tiempo de dos requisitos: ofrecer un 
elevado nivel de seguridad y una gran facilidad de acceso a 
los votantes. En el apartado de la seguridad de la votación 
remota preocupa especialmente que el entorno de votación no 
esté supervisado, es decir, no se controla ni la plataforma del 
votante ni su entorno. Este hecho facilita la posibilidad de la 
coerción de los votantes y la venta masiva de votos. 
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Resumen—Los sistemas de peajes calculan la tarifa que el 
viajero debe pagar en función de los puntos de entrada y salida. 
Estos sistemas se basaban en el papel para realizar este control. 
La progresiva introducción de las tecnologías de la información 
y de las comunicaciones (TIC) permite la utilización de billetes 
electrónicos que reducen los costes y mejoran el control de las 
infraestructuras. No obstante, estos sistemas deben ser seguros 
frente a posibles fraudes, además de preservar la privacidad de 
sus usuarios. En este trabajo proponemos un sistema de peajes 
electrónicos que ofrece un elevado nivel de privacidad a los 
usuarios que actúan honestamente. El proveedor del servicio no 
conoce su identidad y no puede enlazar sus viajes. Sin embargo, 
si los usuarios actúan deshonestamente se puede revocar su 
anonimato. 

Palabras clave—peajes electrónicos, seguridad, privacidad, 
anonimato revocable, no-enlazabilidad, dispositivos móviles 


Il. INTRODUCCIÓN 


La incorporación de las Tecnologías de la Información y las 
Comunicaciones (TIC) en los sistemas de peajes (en inglés 
Automatic Fare Collection systems - AFC) permite reducir 
costes y obtener mejoras de control en las infraestructuras, 
como podría ser la monitorización de la densidad del tráfico 
en tiempo real, o la planificación de las infraestructuras en 
función de los flujos de viajeros. Los sistemas AFC están 
diseñados para el transporte público masivo. El usuario no 
establece previamente su destino, sino que la tarifa se calcula 
en función del lugar por el que entra y del lugar por el que sale 
del sistema. En este sentido, es necesario habilitar una gestión 
segura de las entradas (check-in) y salidas (check-out), dado 
que los usuarios pagan en función de esta utilización. Si el 
sistema identifica a cada usuario y conoce sus movimientos, 
puede hacer un seguimiento de éstos vulnerando su privacidad. 
Por este motivo, los sistemas de peajes deben incorporar 
medidas para preservar la privacidad de los usuarios. 

Nuestra propuesta ofrece una gestión segura del sistema de 
peajes y ofrece un elevado nivel de privacidad a los usuarios 
que actúan honestamente. No obstante, si un usuario no es 
honesto se revela su identidad de manera que puede ser 
castigado. 

En primer lugar, en la sección II, se realiza un estado del 
arte en los sistemas de peajes (AFC) estudiando la seguridad 
y privacidad de las propuestas. Nuestra propuesta está descrita 


en la sección III y en la sección IV se realiza un breve análisis 
de seguridad. Finalmente, las conclusiones se presentan en la 
sección V. 


TI. ESTADO DEL ARTE 


Hemos realizado un estudio de las propuestas de AFC que 
tienen en cuenta el anonimato de los usuarios, y ofrecen 
anonimato revocable [8], [2], [3], [4], [5], [6] . 

En la mayoría de ellas, el proveedor del servicio puede 
enlazar varios viajes de un mismo usuario [8], [2], [4], [5], [6]. 
En [3] el proveedor no puede enlazar los viajes de los usuarios, 
pero para ello los usuarios deben obtener una credencial dife- 
rente para cada viaje. Esto supone un sobrecoste importante en 
sistemas de transporte masivo, donde las entradas y las salidas 
deben ser lo más rápidas posibles. 

En el caso de los dispositivos utilizados, observamos que la 
tendencia va en la línea de utilizar dispositivos móviles (p.ej. 
teléfonos móviles, PDAs, smart phones, etc.) [8], [3], [5], [6] 
para estos sistemas, imponiéndose a las tarjetas inteligentes 
(smart-cards) [21], [3], [4]. 

En el Cuadro I vemos de forma resumida la clasificación 
de las propuestas analizadas según el nivel de anonimato, la 
enlazabilidad, y el dispositivo que se utiliza en estos sistemas. 


Ref. | Anonimato | Enlazable Dispositivo 

[8] Revocable Sí Móvil 

[2] Revocable Sí Smart-card 

EJ] Revocable No Móvil y Smart-card 
[4] Revocable Sí Smart-card 

[5] Revocable SÍ Móvil 

[6] Revocable Sí Móvil 

Cuadro I 


COMPARACIÓN DE LAS PROPUESTAS ANALIZADAS 


Nuestra propuesta ofrece anonimato revocable y no- 
enlazabilidad. La propuesta ha sido diseñada para que los 
usuarios utilicen sus dispositivos móviles en el sistema de pea- 
jes. Cabe destacar que los usuarios no necesitan obtener una 
credencial nueva cada vez que realizan un viaje, a diferencia 
de [3]. 
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TI. SISTEMA DE PEAJES ELECTRÓNICOS 


En esta sección describimos nuestro protocolo que protege 
el anonimato de los usuarios mediante firmas de grupo [1] 
para servicios de transporte masivo. 


TIFC. 


Información en los billetes 


A continuación, mostramos la información que tienen los 


billetes de entrada (Cuadro Il) y de salida (Cuadro III), además 
de mostrar la notación (Cuadro IV). 


A continuación se describen los participantes del sistema, 


BILLETE DE ENTRADA (tin *) 


las propiedades de seguridad, la información de los billetes de 


entrada y salida, y las fases del sistema. 


IFA. Participantes del sistema 


En el sistema propuesto participan los siguientes actores: 


= Usuario 14: accede al sistema de transporte y paga por el 
servicio recibido en la salida. 

= Proveedor de servicios (Ps es origen, Pp es destino): 
estación que controla los billetes utilizados por 14. 

= TTP de pago Mc: gestiona los pagos de los usuarios 


NOMBRE NOTACIÓN DESCRIPCIÓN 

Número de serie Sn generado por Ps 

Estación de entrada Ps identificador de Ps 

Timestamp de entrada T1 marca de tiempo de entrada 

Tiempo de validez Tu tiempo para ser verificado 

Commitment de U as compromiso del usuario firmado 

Firma digital Signs (tin) | contenido firmado por Ps 
Cuadro II 


INFORMACIÓN DEL BILLETE DE ENTRADA 


cuando salen del sistema. 


BILLETE DE SALIDA (tout *) 


= TTP de grupo Mg: gestiona las claves de grupo, las 


listas de revocación de los usuarios, etc. Tiene la potestad 


de revocar el anonimato de un usuario si éste actúa 


deshonestamente a partir de la firma de grupo de los 


NOMBRE NOTACIÓN DESCRIPCIÓN 
Información de validación 0* enviado por U 

Tarifa a cantidad pagada 
Timestamp de pago T5 marca de tiempo del pago 
Firma digital Signp (tout) | contenido firmado por Pp 


billetes de entrada o salida. 


HIFB. Propiedades de seguridad 


Los servicios de transporte siempre dan un recibo o billete 


Cuadro III 


INFORMACIÓN DEL BILLETE DE SALIDA 


a los usuarios para ser posteriormente validados, ejerciendo 


como prueba de que se ha actuado correctamente en el 


sistema. En estos sistemas, al ejecutarse totalmente de forma 


electrónica, se deben cumplir las siguientes propiedades de 


seguridad: 


=  Autenticidad: un billete debe ser generado por su correcto 


emisor. 


= No-repudio: el emisor no puede negar la evidencia de 


haber generado uno de sus billetes. 


= Integridad: el billete, una vez generado, no puede ser 


posteriormente modificado. 


Además de estos requisitos básicos, aparecen otros que tam- 


bién deben cumplirse: 


= Tiempo de validez: no puede utilizarse un billete una vez 


ha expirado su tiempo de validez. 


= No-sobreutilización: no puede utilizarse un billete más 


NOMBRE NOTACIÓN 
Clave pública de grupo gpk 
Lista de claves privadas para cada usuario del grupo gsk[ ] 
Lista de revocaciones del grupo grt[ |] 
Base de exponenciación Q 
Número primo 7) 
Número primo q 
Seudónimo de 11 (para el pago) Yu 
Exponenciación inversa de yyy (secreta) zu 
Número aleatorio ae 
Exponenciación de r Ó1 
Encriptación probabilística de yz 02 
1-ésima marca de tiempo Ti 
Firma digital del contenido content por la entidad E | Signg(content) 
Billete de entrada firmado por Ps tin * 
Reto para U/ para demostrar autoría de yyy C 
Reto y tarifa firmados por Pp para U p* 
Respuesta de 11 al reto c w 
Encriptación probabilística de w Y 
Aceptación del cobro firmada por parte de Me ok* 
Billete de salida firmado por Pp ta 


veces que el número de usos preestablecido. 

= Anonimato revocable: el sistema debe permitir el ano- 
nimato de los usuarios para obtener la aceptación de 
dicha comunidad, aunque el sistema y las autoridades 
públicas preferirían el no-anonimato para los usuarios por 
seguridad y control. De este modo, una solución viable 
y de compromiso es el anonimato revocable para los 
usuarios. Si un usuario actúa deshonestamente se revoca 
su anonimato. 

= No-enlazabilidad: el proveedor únicamente debe poder 
enlazar la entrada con su correspondiente salida, evitando 
entonces la enlazabilidad entre varios viajes de un mismo 
usuario (tracking). 
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Cuadro IV 


INFORMACIÓN DE LA NOTACIÓN, ORDENADA POR ORDEN DE APARICIÓN 


HED. Fases del sistema 


En el sistema se definen las fases siguientes: 


= Configuración inicial: Mg genera todas claves de grupo, 


listas de revocación, etc. 


= Registro del usuario: 14 se registra en Mg, adquiriendo 
un par de claves de grupo. También crea una cuenta 
con Me mediante un seudónimo que será utilizado 


únicamente para los pagos. 


= Entrada en el sistema: los usuarios entran en su estación 
origen y generan una firma de grupo que certifica que 
son usuarios válidos registrados del sistema. Esta firma 
no revela su identidad. A partir de esta firma reciben un 
billete de entrada que deben mostrar a la salida. 

= Salida del sistema: el usuario se autentica otra vez en 
la estación de destino como usuario válido del grupo y 
muestra su billete de entrada. El proveedor Pp calcula 
la cantidad que debe pagar el usuario a partir de la tarifa 
vigente. El usuario acepta el pago y genera la aceptación 
que se envía a Mc. A partir de la aceptación Me carga el 
importe a la cuenta de 14. Si todo el proceso es correcto, 
el usuario recibe un billete de salida. 


IHIFE. Configuración inicial 


Esta fase se ejecuta únicamente una vez para el conjunto 
de usuarios. Mg genera el grupo de tamaño establecido, 
generando como salida (gpk, gsk[ ], grt[ |, a, p, q), siendo gpk 
la clave pública compartida del grupo, cada clave privada del 
usuario es gsk|[i], la lista de usuarios revocados en el grupo es 
grtl ], y (a,p,q) son parámetros públicos, siendo «: la base 
pública de exponenciación, y (p, q) números primos tales que 
p = 2q + 1, cardinales de sus grupos correspondientes Z, y 
Z¿. Además, los proveedores de servicio generarán sus propias 
parejas de claves mostrando sus respectivas claves públicas. 
Las claves privadas de los usuarios gsk|[+i] serán entregadas en 
el momento del registro de cada usuario. 


HIFF. Registro del usuario 


U se registra en la TTP de grupo Mg y recibe la pareja 
de claves de grupo (gpk, gskl[i]). A continuación, UU también 
se registra en la TTP de pago Me; el usuario tiene un 
seudónimo siendo una exponenciación precalculada yy = 0% 
(mód p) dado un cierto valor aleatorio 27, e Z¿; únicamente 
la información yy será mostrada a la TTP de pago Mc, y 
autenticada mediante Schnorr [7] demostrando que se conoce 
Ty Sin darlo a conocer. De este modo, se preserva el anonimato 
para el usuario, pero podría ser revocado por Mg si fuera 
necesario. 


HI-G. Entrada en el sistema 


Cuando el usuario (/ entra correctamente en el sistema 
recibe un billete de entrada t¡n. A la salida del sistema 14 debe 
mostrar el billete para calcular la cantidad que debe pagar. A 
continuación se describe el protocolo de entrada. 


1. El usuario // realiza los pasos siguientes: 


a) genera un valor aleatorio r Pad Za; 

b) calcula 0, = a”  (mód p); 

c) calcula d2 = PK uc (Yu) (el criptosistema utiliza- 
do es probabilístico); 

d) genera un timestamp To; 

e) compone a = (9,,92,70), y lo firma con su clave 
de grupo 0* = (0, Signg(o)); 

f) envía o* a Ps; 

2. El proveedor de servicios origen Ps realiza los pasos 
siguientes: 


a) verifica la firma de o*, es decir, comprueba si es 
un usuario válido del grupo y que no haya sido 
revocado anteriormente; 

b) genera un timestamp 71; 

c) rellena la información del billete de entrada al 
sistema tin = (Sn, Ps, 71,7,,0*) y calcula la firma 
tin" = (tin, Signps (tin)); 

d) envía tin* a UU; 

3. U verifica la firma de t;¡n* y su contenido; 


HFH. Salida del sistema 


Cuando el usuario sale del sistema, envía el billete de 
entrada tin a la estación de salida Pp, y se calcula la cantidad 
que debe pagar. Si 14 actúa honestamente recibe un billete de 
salida toy; como recibo del pago. 

1. U envía tin* a Pp; 

2. El proveedor de servicios destino Pp realiza los pasos 

siguientes: 

a) verifica la firma de t;,* calculada por Ps; 

b) comprueba que tin.Sn no haya sido utilizado en 
anterioridad; 

c) verifica que no haya expirado el tiempo de validez 
Tu; 

d) obtiene un timestamp Ta; 

e) calcula la cantidad a pagar dependiendo del 
punto de entrada (tin.Ps), de salida (Pd) y de 
sus respectivos tiempos (tin.T1 Y 72) a = 
F tin Ps, Pd, tin-71, 73); 

f) genera un reto c pda Za; 

g) compone B = (tin*, a,c, 72, Pd), y lo firma P* = 
(8, Signp,(8)); 

h) envía P* ad; 

3. U realiza los pasos siguientes: 

a) verifica la firma de P* calculada por Pp; 

b) calcula w =r+c<: ty  (mód q); 

c) genera un fimestamp 73; 

d) compone y cifra y = PK pu, (w, tin.Sn, 73, 4); 

e) compone Y = (8*,y,73) y lo firma con la firma 
de grupo: 0* = (0, Signg(0)); 

f) envía 0% a Pp; 

4. Pp verifica la firma de 0* y su contenido, y la envía a 

la TTP de pago Me; 

5. Mc realiza los pasos siguientes: 

a) verifica la firma de 0*; 

b) descifra yy para obtener la prueba de Schnorr para 
ser verificada w; 

c) descifra 0.02 para obtener el seudónimo a quién 
cargar la cuenta del viaje yy; 

d) verifica la identidad de 14 mediante Schnorr: a” E 
d1 + (Yu); 

e) sies correcto, carga la cuenta del viaje con importe 
a al usuario que apunta yy; 

f) genera un timestamp Ta; 

g) genera ok = (tin.Sn,a,74) y lo firma ok* = 
(ok, Sign mu. (ok)); 
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h) envía ok* a Pp; 
6. Pp realiza los pasos siguientes: 


a) genera un timestamp 75; 

b) compone tor = (0*,a,75) y lo firma ton? = 
Corts Signp; (tout); 

c) envía ton” a UY y permite salir al usuario del 
sistema; 


IV. ANÁLISIS DE SEGURIDAD 


Proposición IV.1. El sistema propuesto preserva la autenti- 
cidad, el no-repudio y la integridad de los billetes de entrada 
y salida. 


Afirmación 1. No es posible la creación de billetes de entrada 
o salida fraudulentos. 


Prueba. Los billetes tienen la forma siguiente tin* = 
(tin, Signs (tin)) y tout? = (tout, Signpp (tout)), además de 
la información enviada previa al pago P* = (PB, Signp, (6)). 
Sí una entidad no autorizada puede crear un billete (entrada 
o salida) válido sin disponer de las claves privadas de Ps 
ni de Pp, podría generar firmas digitales en nombre de los 
proveedores. Suponiendo la utilización de un esquema de 
firma digital seguro, esta operación no se considera posible. 
Por otro lado, el usuario envía la información de verificación 
firmada con su clave de grupo: o* = (0, Signg(o)) y 0* = 
(9, Signg(0)). Por el motivo anterior, esta firma garantiza que 
el mensaje es auténtico y ha sido enviado por un usuario válido 
(no revocado) dentro del grupo. 


Afirmación 2. El emisor de un billete no puede denegar la 
emisión de dicho billete. 


Prueba. Los billetes están firmados por su emisor (los provee- 
dores de servicio) y, considerando que el esquema de firma es 
seguro, esta operación solamente la pueden realizar ellos. Por 
lo tanto, la identidad del emisor está asociada al billete y por 
las propiedades del esquema de firma electrónica no pueden 
negar su autoría. De esta misma manera ocurre con la firma 
de grupo, donde si la identidad se revela, puede verificarse la 
autoría de un mensaje. 


Afirmación 3. 
modificado. 


El contenido de un billete no puede ser 


Prueba. Suponiendo que el esquema de firma es seguro y 
que la función resumen utilizada en la firma es resistente a 
colisiones, si se modifica el contenido del billete la verifica- 
ción de la firma de los billetes será incorrecta. Para que la 
verificación fuera correcta se debería volver a generar la firma 
realizada sobre el resumen del nuevo contenido. Como se ha 
mencionado anteriormente, esta operación no es posible con 
los equipos actuales. El mismo argumento se puede aplicar 
con la firma de grupo. 


Resultado IV.1. De acuerdo con las definiciones en la sec- 
ción HH-B y las Afirmaciones 1, 2 y 3, podemos asegurar que 
el protocolo consigue las propiedades de autenticidad, no- 
repudio e integridad. 


Proposición IV.2. El sistema descrito en la sección III satis- 
face la propiedad de anonimato revocable, y los movimientos 
de un mismo usuario no son enlazables entre sí por parte de 
los proveedores. 


Afirmación 4. Un billete es anónimo. 


Prueba. La información relativa a la identidad del usuario 
está cifrada con la clave pública de la TTP de pago. Los 
proveedores (Ps y Pp) no pueden acceder a esta información 
al no disponer de la clave privada de la TTP. En el sistema los 
usuarios calculan dos firmas de grupo (tin.0* = (0, Signg(0)) 
y 0* = (0, Signg(0))) que certifican que el firmante es un 
usuario válido del grupo. Por las propiedades de las firmas 
de grupo los proveedores no pueden obtener la identidad del 
emisor de la firma. Si hubiese algun problema, podría obte- 
nerse la identidad del usuario que generó la firma mediante la 
cooperación de las distintas TTP de pago Me y de grupo Mg. 
Si el usuario aparece en la lista de revocación, se descubre su 
identidad, permitiendo entonces las acciones pertinentes. 


Afirmación 5. El usuario es anónimo frente a los proveedores 
en la operación de pago. 


Prueba. Toda la información relacionada con el pago está ci- 
frada y sólo la TTP de pago puede acceder a ella. Las 
estaciones son externas al pago, y sólo reciben la confirmación 
de parte de la TT'P de pago que éste se ha realizado correcta- 
mente. La TTP de pago Me conoce yy de la dupla (21, Yu) 
donde yu = a%%  (mód p) que lo identifica como usuario; 
entonces, el usuario se autentica mostrando el conocimiento 
de su pareja xy mediante la autenticación de Schnorr [7]. 


Afirmación 6. Múltiples firmas de grupo realizadas por un 
mismo usuario no son enlazables entre sí, por parte de los 
proveedores. 


Prueba. La propuesta de firma de grupo realizada por Boneh 
y Shacham [1] utiliza un modelo de firma probabilístico, es 
decir, no es posible predecir un texto cifrado dado un texto 
plano como entrada. Ello permite la no-enlazabilidad entre 
diferentes firmas de grupo realizadas por un mismo usuario. 


Resultado 1V.2. De acuerdo con las definiciones dadas en la 
sección IHI-B y las Afirmaciones 4, 3 y 6, podemos asegurar 
que el protocolo consigue las propiedades de anonimato 
revocable y no-enlazabilidad. 


Proposición 1V.3. El protocolo no permite la sobreutilización 
de los billetes, además de garantizar el cumplimiento de sus 
fechas de vencimiento. 


Afirmación 7. El protocolo no permite la sobreutilización de 
los billetes. 


Prueba. Si un usuario intenta sobreutilizar un billete (de 
entrada), quedará patente el número de serie utilizado con 
anterioridad. Si se demuestra este acto deshonesto por parte 
del usuario, se puede recurrir a la TTP de grupo Mg para que 
lo incluya en la lista de revocación. 


Afirmación 8. El billete no puede ser válido después de la 
expiración de su tiempo de validez 7,,. 
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Prueba. La estación de salida Pp recibe el billete del usuario 
para ser verificado. En esta verificación, se comprueba que el 
tiempo actual no haya sobrepasado el tiempo de validez 7, 
explícito en el mismo billete t;¡,* firmado por Ps. 


Resultado 1V.3. De acuerdo con las definiciones dadas en la 
sección HI-B y las Afirmaciones 7 y 8, podemos asegurar que 
el protocolo consigue las propiedades de no-sobreutilización 
y el cumplimiento de la fecha de vencimiento. 


V. CONCLUSIONES 


Se ha realizado una propuesta de peajes electrónicos adapta- 
da a los servicios de transporte masivo de usuarios, utilizando 
firmas de grupo para preservar su privacidad. Las firmas de 
grupo permiten revocar el anonimato en el caso de actuación 
corrupta de algún usuario. Nuestra propuesta a diferencia de 
las anteriores no requiere que los usuarios obtengan una cre- 
dencial nueva en cada viaje para conseguir la no-enlazabilidad. 

A partir de esta propuesta, la línea a seguir va en la dirección 
de extender el protocolo implementando un demostrador para 
dispositivos móviles, aprovechando las ventajas de reducción 
de recursos (más rapidez y claves más cortas) que nos permiten 
los operadores bilineales en los que trabaja la firma de grupo 
de Boneh y Shacham [1] a través de criptografía de curva 
elíptica. 
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Abstract—En este artículo estudiamos el caso particular de 
la comparación de dos valores a partir de sus correspondientes 
cifrados. Más concretamente, proponemos un protocolo en el 
que dados los cifrados de dos valores mo y m1, se obtiene 
como resultado el cifrado del valor mayor, esto es un cifrado 
de max([mo,m:), sin que se revele el valor de mo y mi. Para 
ello utilizamos como primitiva los homomorfismos de privacidad 
aditivos y multiplicativos. 

Nos hemos centrado en un escenario en el que un conjunto de 
sensores forman una red de sensores inalámbrica. Utilizaremos 
para ello el homomorfismo de privacidad de Domingo-Ferrer, 
fuertemente utilizado en encenarios de redes de sensores. Nuestra 
propuesta representa una reducción logarítmica en la medida del 
mensaje respecto a las propuestas existentes. 


IT. INTRODUCTION 


Posiblemente debido a las múltiples aplicaciones que han 
surgido en el mundo real, en los últimos años la investigación 
en el campo de las redes de sensores inalámbricas ha sido muy 
intensa. Desde redes capaces de monitorizar la posibilidad de 
un incendio forestal en un bosque hasta redes que facilitan 
el aparcamiento en las grandes ciudades, mejorando de esta 
manera en gran medida el tráfico, múltiples aplicaciones han 
surgido con el principal objetivo de mejorar la calidad de vida. 

Un problema común en las redes de sensores inalámbricas 
es gestionar la información que envían los sensores de la red 
en respuesta de una petición realizada por una baliza o sensor 
especial. El cifrado de cada uno de los mensajes que envía un 
sensor así como el descifrado de todos los mensajes recibidos 
es una de las primeras propuestas, pero resulta altamente 
costosa para los sensores así como poco segura. Es deseable, 
pues, evitar tener que descifrar los mensajes a cada paso. 
Por ello, otra de las propuestas que se han hecho ha sido 
añadir cada uno de los mensajes a medida que un sensor 
añadía sus datos. El principal problema de esta propuesta 
es que la longitud del mensaje es muy elevada (en función 
del número de sensores, que acostumbra a ser muy alto). 
Así, se introdujeron los homomorfismos de privacidad para 
la agregación de datos cultos (CDA, del inglés, Concealed 
Data Ageregation) [7], [8], que permitían agregar los mensajes 
cifrados obteniendo los resultados deseados en los mensajes 
en claro. Diferentes propuestas se encuentran en la literatura. 
Por agregar, entendemos aquí que se calcula una cierta función 
prefijada en un principio y cuyos argumentos son los valores 
que aportan cada uno de los sensores. Generalmente, esta 
función es simplemente la suma de los valores, aunque en 


ocasiones, otras funciones más sofisticadas como aquellas 
que proporcionan patrones de detección de movimiento son 
necesarias [7], dependiendo de los diferentes escenarios de la 
red de sensores en consideración. 

Una función sencilla y enormemente útil en el cálculo dis- 
tribuido es la función que permite calcular la comparación de 
sus argumentos. De hecho, no sólo es útil en escenarios rela- 
cionados con redes de sensores, si no que también es deseable 
en numerosos escenarios más generales. En ella se basan 
operaciones como el cálculo de valores máximos o mínimos. 
Encontrar estos valores puede resultar especialmente útil en 
aplicaciones donde los sensores toman medidas en un entorno 
concreto, ya sea, por ejemplo, un sistema de monitorización de 
incendios o sensores de temperatura o presión. Sin embargo, 
no se conocen muchas soluciones y mucho menos que sean 
eficientes. En [2] se propone una comparación segura de 
datos cifrados basándose en una esquema particular de cifrado 
que mantiene el orden [3], pero la propuesta no es eficiente. 
Posteriormente, en [6], los autores proponen una alternativa 
también basada en los homomorfismos de privacidad, pero la 
longitud de los mensajes es extremadamente grande (función 
de la longitud del espacio de los mensajes en claro), por lo 
que no es conveniente en escenarios como redes de sensores 
inalámbricas. 


A. Contribución 


En este artículo nos centramos en el caso particular de la 
comparación de dos valores a partir de sus cifrados. Más 
concretamente, proponemos un protocolo en el que dados 
los cifrados de dos valores my y m,, se obtiene el cifrado 
del max[mg,m;,) sin necesidad de descifrar cada uno de 
los valores para proceder a la comparación. No se obtiene 
información de los valores my ni m1 al final del protocolo, a 
parte de la que se pueda deducir del propio resultado. 

Para ello hacemos uso de las propiedades de un homo- 
morfismo de privacidad aditivo y multiplicativo. Pese a que 
tiene interés en entornos más generales, nos hemos centrado 
en el escenario de las redes de sensores, donde es conocida la 
necesidad de la comparación de valores. Por ello, a modo de 
ejemplo, describimos el protocolo utilizado el homomorfismo 
de privacidad de Domingo-Ferrer, ampliamente utilizado en 
escenarios de redes de sensores. Para otras aplicaciones, sólo 
es necesario considerar un homomorfismo de privacidad que 
se adecúe al escenario. Nuestra propuesta representa una 
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reducción logarítmica en la medida del mensaje respecto a 
previas propuestas. 


B. Organización del artículo 


El resto del artículo está organizado de la siguiente manera. 
En la Sección II revisamos el concepto de homomorfismo 
de privacidad, detallando en concreto el funcionamiento del 
homomorfismo de privacidad propuesto por Domingo-Ferrer 
en [5]. En la Sección II introducimos el protocolo que nos 
permitirá a dos sensores comparar el texto en claro de dos 
mensajes cifrados sin necesidad de descifrarlos. Finalmente, 
concluiremos en la Sección IV, incluyendo algunas líneas 
futuras de investigación relacionadas. 


TI. HOMOMORFISMOS DE PRIVACIDAD 


El concepto de homomorfismo de privacidad (PH, del inglés 
Privacy Homomorphism) fue introducido por Rivest ef al. 
en el año 1978 [11]. Un homomorfismo de privacidad es 
una transformación de cifrados que permite el cálculo de 
ciertas operaciones en los respectivos mensajes sin cifrar. Las 
transformaciones más usadas son la suma y el producto, dando 
lugar a los homomorfismos de privacidad aditivos y multi- 
plicativos, respectivamente. Así, si llamamos C a la función de 
cifrado, D a la de descifrado, y 2 es una operación matemática 
relacionada con el propio homomorfismo en consideración (en 
general, será la suma y la multiplicación) el homomorfismo 
de privacidad aditivo permitiría calcular 


a+b=D(C(a) 8 C(b)) 
mientras que el multiplicativo permitiría el cálculo de 
axb=D(C(a) 8 C(b)). 


Existen numerosas propuestas de homomorfismos de pri- 
vacidad en la literatura, tanto de clave simétrica como 
asimétrica. Entre otros, podemos citar [11], [9] o [10]. Al- 
gunos propuestas, como [5], [1], [4] son tanto aditivas como 
multiplicativas. 

Puesto que haremos un uso extensivo del homomorfismo 
de Domingo-Ferrer [5] en las siguientes secciones, pasamos a 
describirlo con detalle a continuación. 


A. Esquema de Domingo-Ferrer 


El homomorfismo de privacidad de Domingo-Ferrer es 
simétrico, por lo que se utiliza la misma clave para cifrar 
un mensaje que para descifrarlo. Es probabilístico, ya que en 
el proceso de cifrado se utilizan ciertos valores aleatorios que 
permiten que cifrados de un mismo mensaje sean diferentes. 

El esquema considera un entero positivo d > 2 y un entero 
m que debe tener muchos divisores pequeños así como muchos 
enteros menores que m que puedan ser invertidos módulo m. 
Estos parámetros son públicos. 


La clave secreta es k = (r,m/), donde r € Zi y r”* 
mod m existe. El valor s = log,,,'m es un parámetro de 
seguridad. 


Sea a E Zin, el valor que se quiere cifrar. El cifrado y 
descifrado serían como sigue: 


- Cifrado: Se divide el valor a € Z,” aleatóriamente en 
d fragmentos a1,...,4q, de manera que a = a Q; 
mod m/ i a; € Z,, y se calcula: 


Ex(a) =(ajr mod m,...,agr? mod m). 


- Descifrado: Calculando, r7? se obtiene la ¡-ésima coor- 
denada, esto es, az. Después de efectuar este paso para 
todas las coordenadas, se calcula: 


d 
D,(Ej(a)) = E az mod n?. 
¿=1 


Como hemos comentado anteriormente, este homomorfismo 
es aditivo y multiplicativo. Para calcular la suma de los 
mensajes sin cifrar a partir de los propios cifrados se debe 
calcular la suma, componente a componente, de los cifrados. 
Para calcular el producto de los mensajes sin cifrar funciona de 
manera semejante al producto de polinomios, interpretando la 
d tupla como los coeficientes de un polinomio de grado d— 1. 
Se calcula el producto cruzado de todos los términos, esto es, 
los de grado d¡ con los de grado da, resultando en un término 
de grado di + d2. Finalmente, los que tienen igual grado se 
suman. 


B. Cómo Agregar Datos con Homomorfismos de Privacidad 


Los homomorfismos de privacidad han sido muy utilizados 
para agregar datos que se encuentran cifrados proporcionando 
así confidencialidad a las redes de sensores inalámbricas de 
manera eficiente. Así, cuando un sensor recibe información 
cifrada de otro nodo de la red, agrega su valor a través 
del cifrado correspondiente, y reenvía el resultado al sigu- 
lente nodo sin necesidad en ningún momento de descifrar 
el mensaje que se ha recibido. Por agregar entendemos aquí 
al cálculo de una cierta función prefijada en un principio y 
cuyos argumentos son los valores que aportan cada uno de 
los sensores. Generalmente, esta función es simplemente la 
suma de los valores, aunque en ocasiones otras funciones 
más sofisticadas como aquellas que proporcionan patrones de 
detección de movimiento son necesarias, dependiendo de los 
diferentes escenarios de la red de sensores en consideración. 

Aquellos nodos de la red que agregan datos se conocen 
comúnmente como agregadores. Dependiendo de la naturaleza 
de la propia red, se asume que sólo algunos nodos tienen 
las características suficientes para agregar los datos o bien 
cualquier nodo es capaz de realizar dichas operaciones. 

Como hemos comentado anteriormente, aunque existen ho- 
momorfismos de privacidad basados en el paradigma de la 
clave pública, la complejidad de los algoritmos así como las 
limitaciones de los sensores, hacen que en general no sea la 
opción más utilizada para garantizar la confidencialidad de los 
datos que circulan por la red. Así, uno de los homomorfismos 
más utilizados es el de Domingo-Ferrer, de clave privada, y 
que hemos descrito en la Sección IL-A. 

Aunque en [12], Wagner mostró una ataque con texto en 
claro escogido del homomorfismo que hemos descrito en 
ILA para ciertos parámetros, como se muestra en [13], el 
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homomorfismo de privacidad de Domingo-Ferrer resulta más 
seguro que cifrar y descifrar en cada uno de los sensores. 
Existen propuestas más seguras, especialmente considerando 
homomorfismos en el paradigma de clave pública, sin embargo 
el coste computacional y de comunicaciones hace que tales 
soluciones en general no sean deseables en escenarios de 
redes de sensores, especialmente en protocolos que hacen un 
uso intensivo de estos homomorfismos. De hecho, los autores 
también apuntan que para un adversario que intente obtener 
información confidencial, es razonable romper el mecanismo 
siempre y cuando el coste de romper el esquema sea mejor 
que el valor de la información que se cifra. 


III. COMPARACIÓN DE VALORES CIFRADOS 


En esta sección describiremos el protocolo que nos permite 
comparar dos valores a partir de sus respectivos cifrados 
obteniendo como resultado el cifrado del valor que resulta 
mayor en la comparación. El protocolo es válido considerando 
cualquier homomorfismo de privacidad que permita tanto la 
suma como la multiplicación. Por ceñirnos a un escenario con 
una red de sensores inalámbrica, consideraremos el homomor- 
fismo de privacidad de Domingo-Ferrer, ampliamente utilizado 
en entornos de redes de sensores, ya que resulta especialmente 
eficiente en estos entornos. 

Supongamos que un sensor S¡ recibe un valor cifrado 
Ci(mpo) de otro sensor Sy de la red, donde Cy es un 
homomorfismo de privacidad simétrico como el descrito en la 
Sección II-A. El mensaje my pertenece a un rango [—R, R], 
donde R es un valor conocido a priori. Supongamos que 
el sensor S1 tiene el valor m, € [—R,R]. Evidentemente, 
puede calcular C(m,). A continuación describiremos un 
protocolo que nos permitirá calcular C¿(f(mo,m1)), donde 
F(mo, m1) = max([mo, m1) sin necesidad de descifrar en 
ningún momento los mensajes, solución que no resulta de- 
seable por la complejidad de cálculo que puede acarrear 
y especialmente porque en los momentos en los que los 
datos se encuentran descifrados se encuentran especialmente 
vulnerables a los ataques de intrusos. Observermos que en este 
caso, el sensor S1 podrá deducir si my es mayor o menor que 
m1, pero no cuál es su valor exacto. Esto es debido a que en 
este caso el sensor S¡ parte conociendo el valor de m;. En 
el caso general, donde sólo se conocer los valores cifrados tal 
deducción no es posible. 


A. Escenario 


Sea S una red de sensores y sean S¡,...,S¿ los sensores 
que integran la red. Supondremos que una baliza o sensor 
fuente (incluso podemos asumir que se trata del propietario 
de la red) lanza a los sensores de la red una determinada 
petición, como puede ser, por ejemplo, que cada sensor mida 
la temperatura ambiental del lugar donde se encuentre ubicado. 
El mensaje lo recogen un grupo de sensores que se encuentran 
en una zona físicamente más próxima a la baliza y lo dispersan 
a través del resto de sensores. Así, cada sensor S;¡ tendrá 
un valor m,, para todo ¿ € 4(1,...,£%+. Supondremos que 
cada sensor conoce una clave secreta k = (r,m/), según el 


criptosistema de Domingo-Ferrer descrito en la Sección II-A. 
Se requiere además que el valor m” sea suficientemente grande 
de manera que el rango de posibles valores que puedan obtener 
cada uno de los valores de la red sea menor que m/, y así sea 
posible comparar los valores heredando el orden natural de los 
enteros. 

Sería deseable disponer de un dispositivo que garantice el 
uso de los valores secretos para poder cifrar sin que sea posible 
(o al menos, sea costoso) acceder a ellos. Ello prevendría de 
posibles ataques de intrusos. Notaremos C¿.(-) al cifrado de 
un mensaje utilizando este homomorfimos y Dy(-) al proceso 
de descifrado, y definiremos como C7.(-), para r € N, la 
aplicación que cifra utilizando Cz(-) en cada una de las r 
coordenadas de la r-tupla, esto es, Cf. (-) = C()x...xCr(-). 
Por simetría definimos de la misma manera Dj, (-) = D(-) x 
O E E(-). 

Nos centraremos en el caso de la comparación de dos 
mensajes cifrados. Esto es, supondremos, como ya hemos 
dicho anteriormente, que un sensor Sy recibe un valor cifrado 
Co = Ci(mo) de otro sensor Sy de la red y que el objetivo 
es comparar el mensaje my del sensor Sy con el mensaje m1 
que tiene el sensor S sin necesidad de descifrar Cp. Estamos 
suponiendo pues que todos los sensores pueden y deben efec- 
tuar la comparación. En el caso de que no sea así, y no todos 
los sensores sean agregadores, si no sólo algunos de ellos, 
el protocolo que describiremos a continuación en la Sección 
IM-B lo llevará a cabo el sensor agregador con la diferencia 
de que no habrá recibido un único mensaje cifrado, si no un 
conjunto de r de ellos, por lo que deberá aplicar reiteradamente 
y de manera óptima nuestro protocolo para obtener el resultado 
deseado, utilizando cualquier protocolo que permita comparar 
de manera eficiente los diferentes valores del conjunto. 


B. Protocolo 


Dados los sensores Sy y 51, con sendos mensajes my y M1, 
el protocolo que proponemos nos permitirá obtener un cifrado 
de max(mp,m1) sin necesidad de recuperar ni my ni my. 

Para ello, el sensor Sy debe enviar a S¡ el texto cifrado 
de la siguiente manera. El sensor Sy calcula la representación 
binaria de mo, que notaremos (mpy)2 = (0, Or -1,...,01), 
donde r > K, siendo K = log, R. Completaremos con zeros 
por la izquierda hasta completar la tupla de longitud r. A con- 
tinuación, calcula Co = Ci.((Mo)2) = (Cy(ar),..., Crla1)). 

Una vez S1 recibe Co, calcula (mi )2 = (Br, Br-1,...,B1), 
y Ci = Cp ((m1)2) = (Cr(Br), . - -, Cr(B1))- 

A continuación, 51 calcula Cop = C1 — Co y Cio = 
Cio * C10, donde x representa el producto componente a 
componente de los dos vectores. Debido a las propiedades 
homomórficas del criptosistema utilizado, observemos que 
Cio = (Cil), ---, Cr(1)), donde 
si 0% = Bi 
si Qí Á Bi 
para todo ¿= 1,...,r. 


El siguiente paso es calcular un cifrado aleatorio de 1, 
esto es, 4, = Cy(1), y sucesivamente las diferencias a; = 
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Ar — (Cf o0)iai+1, donde (Co): representa la ¿-ésima co- 
ordenada de la r-tupla Cf y, para 1 = r—1,...,1. Así, 
no es difícil comprobar que la r-tupla 4 = (9,,...,01) = 
(Cho), ar-1[(Cio)r-1,---,a1(Cfo)1) se corresponde con 
una r-tupla (Cx(er),..., Cr(€1), donde 


€¡ = da 
a 0, 


El sensor Si calcula el producto escalar de los dos vec- 
tores 0 y Cop, llamémosle A = 8 - Cp, obtendrá Cx(1) si 
mo > mi y Cg(0) si mo < my. Así pues, si calcula 
ACo— (a, — A)C;, obtendrá como resultado Cy (F(mo, m1), 
donde f(mo, m1) = max[mo, m1). 

Finalmente, el sensor S envía al resto de sensores de la red 
ACo + (a, — A)C¡, que serán comparados con los propios 
valores de los sensores de la red. 


sii= mMaxXj=1,.. 11) | Vi NN 1 
en caso contrario 


IV. CONCLUSIÓN 


Encontrar el valor máximo o mínimo de entre un conjunto 
de valores de una red de sensores puede ser de gran interés, 
especialmente en aplicaciones donde los sensores toman me- 
didas en un entorno concreto, ya sea, por ejemplo, un sistema 
de monitorización de incendios o sensores de temperatura o 
presión. Sin embargo no se conocen demasiadas propuestas 
que propongan una solución satisfactoria a dicho problema. 

En este artículo proponemos una solución. Para ello, nos 
centramos en comparar dos a dos, los valores de dos sensores. 
Extendiendo reiteradamente al resto de sensores de la red, 
obtenemos el resultado deseado. Para ello, hemos utilizado los 
homomorfismos de privacidad, que ya han sido especialmente 
utilizados en la literatura en el escenario de las redes de 
sensores inalámbricas. Especialmente, utilizamos el homomor- 
fismo de privacidad de Domingo-Ferrer, que permite, no sólo 
calcular la suma de los mensajes en claro a partir de los 
respectivos mensajes cifrados, si no también la multiplicación. 
Nuestra propuesta representa una reducción logarítmica en la 
medida del mensaje respecto a previas propuestas. 

Pese a la reducción de la longitud de los mensajes, la pro- 
puesta que presentamos aquí continúa siendo compleja para ser 
eficientemente utilizada en una red de sensores inalámbrica. 
Así pues, protocolos alternativos más eficientes son una línea 
de trabajo futuro. Aplicaciones relacionadas, como por ejem- 
plo calcular aquellas regiones donde los sensores miden un 
valor superior a un valor prefijado que se lanza al inicio del 
protocolo serán también objeto de estudio por los autores. 
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Abstract—La tecnología EPC (Electronic Product Code) está 
basada en la utilización de radio-etiquetas de bajo coste. El uso 
de estas radio-etiquetas proporciona una gran flexibilidad para la 
identificación de objetos en movimiento en cadenas de suministro 
y de producción industrial. Sin embargo, la carencia de 
mecanismos específicos de seguridad que garanticen propiedades 
tan indispensables como autenticación o confidencialidad no se 
recogen actualmente en las especificaciones del estándar EPC. 
Por ello, es difícil hoy en día hablar del uso de esta tecnología 
sin que nos venga a la mente problemas de seguridad y de posibles 
violaciones a la privacidad de sus usuarios. Presentamos en este 
artículo una vista rápida a la familia de amenazas a las que se 
enfrenta la tecnología EPC. 

Index Terms—RFID, EPC Gen2, modelo de adversario, 
seguridad, privacidad. 


I. INTRODUCCIÓN 


La tecnología EPC (del inglés, Electronic Product Code), se 
basa en la utilización de dispositivos RFID (Radio Frequency 
IDentification) [1]. Esta tecnología está destinada a ser 
la sucesora de los hoy omnipresentes códigos de barras. 
Diseñada en los laboratorios Auto-ID del MIT (Massachusetts 
Institute of Technology) y más adelante desarrollada por el 
consorcio EPCeglobal Inc., la tecnología EPC representa el 
elemento clave de una arquitectura distribuida conocida como 
EPCglobal Network. Los elementos principales de un sistema 
RFID son las etiquetas electrónicas, los lectores y los sistemas 
de información (servidores y bases de datos). El objetivo de 
esta arquitectura es la identificación automática de objetos 
en movimiento en cadenas de suministro y de producción 
industrial. 

Las etiquetas electrónicas del sistema EPC, cuyas 
características principales se detallan en la Tabla L, son pasivas 
(se alimentan del campo eléctrico generado por el lector, 
debido a la ausencia de batería en la etiqueta). Funcionan en 
la banda Ultra High Frequency (UHE), siendo en Europa entre 
los 865 y 868 MHz. El rango de lectura entre lector y etiqueta 
se sitúa alrededor de los 5 metros. Su funcionamiento responde 
al modelo de una máquina de estados. En un sistema RFID de 
bajo coste como el EPC Gen2 las etiquetas electrónicas tienen 
una capacidad muy limitada, permitiendo reducir su coste por 
debajo de los 10 céntimos [3], pero a su vez, con severas 
limitaciones para gestionar las amenazas de seguridad. 

Como sucede en otras tecnologías emergentes, la falta 
de seguridad y las amenazas contra los componentes de la 


TABLE I 
PRINCIPALES CARACTERÍSTICAS DE LA TECNOLOGÍA EPC GEN2 
Identificador 96 bits 
Rango de lectura =5Sm 
Consumo etiquetas “10 uW 
Frecuencia 865-868 MHz (UHF) 
Ratio Tx etiquetas 40 - 640 kbps 
Ratio Rx etiquetas 26.7 - 128 kbps 
Identificaciones por segundo | “200 


arquitectura pueden comportar múltiples inconvenientes a sus 
usuarios (por ejemplo, difusión de datos privados y pérdida 
de intimidad). El presente artículo se centra en las amenazas 
a la integridad de las comunicaciones entre los lectores y las 
etiquetas electrónicas, debido a la limitación de las etiquetas 
en el sistema EPC Gen2, y al uso de un canal inalámbrico 
inseguro que no garantiza la autenticidad de las entidades 
participantes en el sistema [4]. 

El análisis de las vulnerabilidades relativas a la 
comunicación entre el lector y el sistema de información no 
se considera en este artículo, puesto que estos equipos tienen 
la potencia suficiente para ejecutar los mecanismos de cifrado 
necesarios, además de utilizar canales de comunicación más 
seguros como interfaces cableadas de red local. 

De este modo para el resto del artículo nos referimos a 
la comunicación entre etiquetas y lectores EPC por el canal 
de radiofrecuencia como sistema EPC Gen2 , en donde se 
encuentran la mayoría de las vulnerabilidades de seguridad. 

El modelo de comunicación en el sistema EPC Gen2 es 
común al del resto de sistemas RFID de bajo coste, en 
donde el lector inicia la comunicación (ITE interrogator talks 
first, del inglés) ya que la etiqueta es pasiva y necesita de 
la energía del lector para responder. Concretamente existen 
tres etapas en la comunicación entre un lector y etiqueta 
EPC Gen2. En las etapas de selección e inventariado, 
el lector inicia la comunicación lanzando una petición 
de identificación (request). Las etiquetas presentes en el 
rango de lectura responden (response) con un identificador 
provisional. En el momento en que el lector responde 
al identificador provisional (acknowledge), las etiquetas 
devuelven el identificador completo de 96 bits [1]. En este 
punto si el lector quiere acceder a contenidos de la memoria 
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reservada, o modificar partes de la memoria de la etiqueta, 
se entra en la etapa de acceso. La Sección II profundiza en 
esta etapa, en que la comunicación lector-etiqueta se cifra para 
no revelar datos sensibles del sistema, mientras que el canal 
etiqueta-lector se transmite sin cifrar. 

Como se ha comentado previamente, la característica 
principal del sistema EPC Gen2 es la simplicidad y bajo 
coste de las etiquetas electrónicas. Este punto es determinante 
para la inclusión de posibles mejoras de seguridad que den 
respuesta a las amenazas que se detallarán en la Sección III, 
debido a las vulnerabilidades relacionadas con la restricción 
de la capacidad de computación, memoria y energía, presentes 
en el sistema EPC Gen2 [5]. 

En este artículo, presentamos una visión general sobre la 
familia de amenazas contra la tecnología EPC. Describimos el 
modelo de adversario del sistema EPC Gen2, las principales 
vulnerabilidades existentes en la tecnología y los puntos 
que podrían ser explotados por un atacante para hacer 
efectivas las amenazas. El resto del artículo se organiza 
de la siguiente manera. La sección II presenta el modelo 
de adversario que supondremos durante la presentación de 
las vulnerabilidades, y las peculiaridades de la tecnología 
EPC que hacen posible suponer dicho modelo. La sección 
III describe una presentación general sobre el conjunto de 
amenazas seleccionado para nuestro estudio. La sección IV 
cierra el artículo con un conjunto de conclusiones. 


TI. MECANISMOS DE SEGURIDAD EN EPC GEN2 


Todo sistema de comunicaciones padece amenazas 
relacionadas con la seguridad de la información gestionada 
por el sistema. Por este motivo es importante determinar 
la naturaleza de dichas amenazas e identificar los posibles 
adversarios, para poder analizar las medidas de seguridad a 
adoptar y en qué circunstancias deben ser implementadas. 

Las amenazas relativas a la seguridad y privacidad de los 
datos transmitidos en un sistema EPC Gen2, vienen dadas por 
el valor intrínseco del objeto etiquetado, o del valor derivado 
de correlacionar la información de la etiqueta con la identidad 
del individuo que está identificando [6]. 


A. Modelo de adversario: definiciones 


Para evaluar los principales problemas de seguridad que 
pueden afectar un sistema EPC Gen2, se debe definir 
un modelo simple contemplando las características de 
comunicación del sistema EPC Gen2 de REID de bajo coste, y 
los posibles adversarios, así como las capacidades y objetivos 
de ambos. En primer lugar se listan las principales entidades 
del sistema EPC Gen2 participantes en el modelo, así como 
una descripción de sus características. Para un análisis más 
amplio de modelos de adversario para RFID de bajo coste 
puede consultarse [7]. 


. Lector autorizado: El que estando registrado en el sistema 
dispone de los mecanismos necesarios para acceder a 
los contenidos restringidos de la memoria. Por tanto el 
lector autorizado puede leer y escribir en las etiquetas 
electrónicas. 


. Etiqueta legítima: Una etiqueta electrónica presente en 
la base de datos del sistema, y que ha sido previamente 
identificada por un lector autorizado. 

e Lector no autorizado: El que no está registrado en el 
sistema, pero tiene acceso al rango de lectura del sistema 
EPC Gen2. 

e Etiqueta ilegítima: Etiqueta fraudulenta que accede 
al rango de lectura de un sistema EPC. Cuando la 
identificación de una etiqueta fraudulenta ha sido copiada 
de una etiqueta legítima, se conoce como etiqueta 
clonada. 


A continuación, se definen las características del canal de 
comunicaciones. 


. Canal lector-etiqueta: Trasmisión de lector a etiqueta. 
El lector transmite a una potencia muy superior a la de 
la etiqueta, ya que esa energía debe ser suficiente para 
alimentar la respuesta de la etiqueta. Por este motivo, el 
canal lector-etiqueta puede ser capturado a centenares de 
metros del punto de transmisión [2]. 

. Canal etiqueta-lector: Transmisión de etiqueta a lector. 
Como se ha citado en la Introducción, las etiquetas 
electrónicas del sistema EPC Gen2 son pasivas, por 
lo que no disponen de una fuente de energía en la 
propia etiqueta. La transmisión se realiza mediante la 
señal proveniente del lector reflejado por la antena de la 
etiqueta, por lo que su alcance se limita a unos 5 metros. 


Finalmente, se definen los dos modos de interacción básicos 
entre lector y etiqueta, la identificación y el acceso. 


. Identificación: La etiqueta electrónica legitima o ilegítima 
transmite (en claro) los 96 bits de su código EPC de 
identificación tras completar los estados de selección e 
inventariado. 

+. Acceso: Una vez completada la identificación de 
la etiqueta electrónica, un lector (autorizado o no 
autorizado) se dispone a activar los mecanismos de 
seguridad para poder acceder a todo el contenido de la 
memoria de la etiqueta para leer o escribir en ella (la 
Tabla II detalla la esctructura lógica de la memoria). Los 
peticiones de acceso a la memoria de una etiqueta EPC 
Gen2 pueden ser read, write, kill, lock, access, blockwrite, 
blockerase y block permalock [1]. 


Una vez definidas las características básicas del sistema 
EPC Gen2, pasamos a describir los posibles tipos de 
adversarios del sistema. Para el modelo de adversario del 
sistema EPC Gen2 se supone que las etiquetas y los lectores no 
autorizados se encuentran, salvo que se indique lo contrario, 
a una distancia superior a la del rango de lectura del 
canal etiqueta-lector. El motivo por el que este modelo 
prioriza las amenazas sobre el canal lector-etiqueta, es debido 
a la sencillez de capturar la información de este canal 
mediante cualquier lector compatible EPC Gen2 a distancias 
de centenares de metros. El canal etiqueta-lector, en cambio, 
necesita de equipos especiales con antenas muy directivas, O 
bien situarse dentro del rango de lectura del canal (alrededor 
de 5 metros). 
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TABLE HU 
MAPA LÓGICO DE LA MEMORIA DE LAS ETIQUETAS EPC GEN2 


User: 
TID: 


Opcional 
TID [15:0] 
TID [31:16] 

XPC_W1 [15:0] 
EPC [15:0] 


EPC: 


EPC [95:79] 
PC [15:0] 

CRC [15:0] 
Access Password [15:0] 
Access Password [31:16] 

Kill Password [15:0] 
Kill Password [31:16] 


Reserved: 


e. Vulnerabilidad: Es la propiedad del sistema que un 
adversario trata de atacar para conseguir el objetivo de 
la amenaza. 

e Amenaza: Es el objetivo del adversario para violar una 
vulnerabilidad relativa a la seguridad del sistema. 

+ Adversario pasivo: Es la entidad que trata de explotar una 
vulnerabilidad en el sistema para ejecutar la amenaza [8]. 
Se limita a capturar información en el rango de lectura, 
sin dar evidencias de su presencia en el sistema. 

+. Adversario activo: Igual que el adversario pasivo, pero 
puede transmitir y recibir información en el rango de 
lectura. En caso de poder situarse en el rango del canal 
etiqueta-lector, también podría afectar el contenido de la 
memoria de las etiquetas. 


B. Seguridad del sistema EPC Gen2 


El protocolo de comunicación del sistema EPC Gen2 se 
basa en un sistema de petición-respuesta (request-response) 
entre lector y etiquetas electrónicas en tres etapas diferentes 
(selección, inventariado y acceso), en el que la etiqueta pasa 
por diferentes estados. La integridad de los mensajes se 
comprueba mediante un código de redundancia cíclica (CRC) 
de 16 bits. La identificación de una etiqueta se realiza de 
manera automática por cualquier lector compatible EPC Gen2, 
sin ningún tipo de autenticación segura por ambas partes. Es 
decir, cualquier lector puede identificar etiquetas en el rango 
del canal etiqueta-lector. 

Por contra, el protocolo de comunicación para EPC Gen2 
sí incluye mecanismos básicos de seguridad para la etapa de 
acceso a las etiquetas electrónicas. El estándar EPC Gen2 
incluye en sus especificaciones una contraseña de 32 bits 
para el acceso a la memoria de la etiqueta electrónica. 
Además el estándar incluye una contraseña de 32 bits para 
la opción kill, que en caso de ser activada permite desactivar 
el funcionamiento de la etiqueta de forma permanente, oO 
bien desbloquear determinadas partes de la memoria de la 
etiqueta electrónica previamente bloqueadas, en función de la 
codificación del comando como kill o como recommission [1]. 


Lector 
EPC Gen2 


— — - Req_RN (RN16) 


Etiqueta 


____—-— Handle - 


7 Req_RN (Handle) 


RAN16' - — 7 


Kill (Pwd 31:16 € RN16) 


____ Handle = 77 


— — Req_RN (Handle) 


A 


Kill (Pwd 15:0 Y RN16") 


Header,Handle  — 


Fig. 1. Protocolo para ejecutar la opción kill en EPC Gen2. 


Las contraseñas de acceso y kill se almacenan en la memoria 
reservada de la etiqueta electrónica (la Tabla II contiene las 
diferentes áreas de memoria de una etiqueta EPC Gen2). 

Adicionalmente, para evitar revelar información sensible en 
el canal lector-etiqueta (por ejemplo contraseñas o nuevos 
identificadores) que pudiera ser capturada por un lector no 
autorizado, las etiquetas electrónicas EPC Gen2 incluyen un 
generador de números pseudo-aleatorios (PRNG) para cifrar la 
información transmitida en ese canal. De este modo, cuando el 
lector requiere el acceso a la etiqueta, ésta transmite en plano 
claves de 16 bits al lector para cifrar el contenido a transmitir 
mediante una operación de OR-exclusiva a nivel de bit. 

Por ejemplo para ejecutar la opción kill a una etiqueta EPC 
Gen2, el lector debe identificar previamente la etiqueta. Una 
vez la etiqueta ha enviado los 96 bits de su código EPC de 
identificación, el lector procede a la fase de acceso (Fig. 1). 
Para ello el lector solicita a la etiqueta una clave de 16 bits 
(RN16) como llave de la sesión de acceso. Cuando la etiqueta 
le proporciona el RN16 (representado como Handle), el lector 
solicita una nueva clave (RN16”) para iniciar el cifrado de 
la contraseña de kill. Esta operación se repite para las dos 
partes de la contraseña de kill (Pwd [31:16] y Pwd [15:0]) 
con una nueva clave RN16”. Para confirmar la finalización de 
la operación, la etiqueta transmite un último mensaje formado 
por una cabecera y el código Handle. 


TII. PRINCIPALES PROBLEMAS DE SEGURIDAD 


Tras definir el modelo de adversario para los sistemas EPC 
Gen2, se pueden destacar las siguientes vulnerabilidades, con 
la correspondiente amenaza de ser explotadas por parte de un 
adversario [6]: 
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+ El canal etiqueta-lector es un canal inseguro. 

+ Cualquier lector compatible con EPC Gen2 puede acceder 
a la identificación y acceso de las etiquetas en el rango 
del canal lector-etiqueta. 

e El diseño de las etiquetas está optimizado para reducir su 
coste, por lo que su capacidad es muy reducida y carece 
de mecanismos de seguridad y autenticación fiables. 


Aunque el contenido de las transmisiones entre lector y 
etiqueta en el modo de acceso esté cifrado, el hecho de que las 
claves de cifrado circulen en claro por el canal lector-etiqueta 
representa una vulnerabilidad con riesgo de ser atacada por un 
adversario. 

Por ejemplo el uso de PRNGs con malas propiedades 
estadísticas, o con cierto grado de predictabilidad, puede 
suponer riesgos graves en la confidencialidad de las 
comunicaciones, como se demuestra en [9]. Un lector no 
autorizado puede acceder el canal lector-etiqueta de lectores 
autorizados y etiquetas legítimas. De este modo un adversario 
pasivo podría analizar la predictabilidad de las secuencias 
pseudo-aleatorias generadas en una etapa de acceso. Si el 
adversario puede obtener información sobre la generación de 
las secuencias pseudo-aleatorias, le será suficiente con realizar 
una operación de OR-exclusiva entre la transmisión cifrada y 
las secuencias predichas, para descifrar el mensaje. De este 
modo un lector no autorizado en el rango del canal lector- 
etiqueta, obtendría acceso a las zonas de memoria reservadas 
de la etiqueta tales como contraseñas de acceso y kill. 

En los siguientes subapartados se detallan las cuatro 
principales amenazas a la seguridad en un sistema EPC Gen2. 


A. Escuchas fraudulentas 


Dado que el modelo de comunicación para un sistema REID 
pasivo como EPC Gen2 contempla potencias de emisión 
del lector mucho mayores que la potencia de emisión de 
las etiquetas, las escuchas fraudulentas se definen como 
la presencia de lectores no autorizados con acceso a la 
comunicación del canal lector-etiqueta. Esto no excluye la 
presencia de lectores no autorizados en el canal etiqueta-lector, 
pero es menos probable. 

El canal de comunicación entre lectores y etiquetas es 
fácilmente accesible dada la inseguridad del canal inalámbrico, 
con lo que la confidencialidad de los datos transmitidos es 
fácilmente vulnerable. Como se ha visto al inicio de esta 
Sección, un adversario puede aprovechar la vulnerabilidad de 
un PRNG predecible para obtener la información almacenada 
en la memoria reservada de la etiqueta. 

Relacionados con las escuchas fraudulentas existen los 
ataques de eavesdropping o análisis, en los que un lector no 
autorizado podría interceptar la comunicación y analizarla para 
tratar de descifrar las contraseñas de acceso y kill. 

Por ejemplo un adversario situado en el rango de lectura 
del canal lector-etiqueta de un centro de fabricación textil, 
en donde se identifica cada producto con una etiqueta EPC, 
podría recoger información como el número de unidades 
fabricadas, el modelo o el valor de la producción en cada 
momento. Si en cambio las etiquetas se utilizan para la 


identificación de personas, amenazas a la privacidad personal 
como seguimiento (en inglés, tracking) y análisis de perfiles 
y preferencias (en inglés, profiling/clustering) están incluidas 
en esta categoría [10]. 


B. Suplantación de identidades 


Debido al bajo coste de las etiquetas electrónicas, la tecnología 
EPC Gen2 se utiliza para la identificación a nivel de objetos 
O personas [2]. Su diseño está centrado en la simplicidad de 
sus operaciones, lo que permite identificar un gran número 
de etiquetas de forma simultánea (Tabla ID). Puesto que el 
sistema EPC no dispone de mecanismos de autenticación, el 
adversario no encontraría ninguna dificultad para conseguir la 
misma información que podría obtener un usuario autorizado 
dentro del sistema. 

Un lector no autorizado podría suplantar (spoofing) un 
lector autorizado, obteniendo la identificación de etiquetas 
legítimas. Esta información se podría reproducir en etiquetas 
ilegítimas o fraudulentas por ejemplo mediante un ataque de 
skimming, lo que significaría un caso de clonación de etiquetas 
(cloning) que podría usarse para falsificación de productos 
(counterfeiting). Un lector autorizado no podría discernir 
entre una etiqueta legítima y una etiqueta clonada al no 
existir mecanismos de autenticación para la identificación de 
etiquetas. Del mismo modo, en un sistema de acceso personal 
basado en la tecnología EPC Gen2, se podría suplantar la 
identidad de una persona copiando la identificación de su 
etiqueta a una etiqueta ilegítima, obteniendo los privilegios 
de acceso de la persona suplantada. 

En el caso que existiera la posibilidad de acceder al rango 
de lectura del canal etiqueta-lector, un lector no autorizado 
podría realizar ataques activos como replay O scanning para 
obtener información de las etiquetas directamente. 


C. Divulgación de información 

El riesgo derivado de la suplantación de identidad en un 
sistema EPC Gen2 va más allá de la posible falsificación o 
clonación de etiquetas electrónicas. Como se ha comentado al 
inicio de la Sección Il, las posibles amenazas a la seguridad 
y privacidad de un sistema de información están directamente 
relacionadas con el valor económico de la información que 
pueda obtenerse. 

Esta amenaza es especialmente relevante debido a que 
el código EPC puede revelar información importante como 
la marca, el modelo o el precio del producto, así como 
las estrategias de producción o distribución de la empresa 
en cuestión. De este modo el adversario puede obtener un 
beneficio económico de la venta de esta información con fines 
de espionaje industrial [8]. 

Divulgar secretos industriales es una actividad claramente 
ilegal, por lo que el adversario no tomará riesgos innecesarios 
como acceder a los recintos de producción o distribución. 
En cambio el adversario puede aprovechar el largo alcance 
del canal de comunicación lector-etiqueta para obtener la 
información deseada desde centenares de metros [4]. 
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En el plano personal esta amenaza es también relevante, ya 
que supone una invasión de la privacidad de los usuarios del 
sistema. Podemos imaginar un escenario en el que la actividad 
de un grupo de usuarios sea registrada por un adversario con 
un lector no autorizado, para luego obtener beneficio de esa 
información. 


D. Denegación de servicio 


La denegación de servicio (DoS) es una amenaza que tiene 
por objetivo limitar o anular la funcionalidad de un sistema 
de información. En el caso del sistema EPC Gen2, la 
denegación de servicio significaría dejar inoperativo el canal 
de comunicación (tanto de lector a etiqueta como viceversa) 
haciendo inviable el intercambio de información. 

Una denegación de servicio podría realizarse de diversos 
modos tomando como referencia el modelo especificado 
en la Sección H. Por ejemplo, un emisor de radio- 
frecuencia emitiendo señal de ruido (ataque jamming) 
entre las frecuencias 865 y 868 MHz en el rango de 
lectura del canal lector-etiqueta, ocuparía los canales de 
comunicación del sistema EPC Gen2, impidiendo que los 
lectores autorizados iniciaran la selección e identificación de 
las etiquetas electrónicas [1]. Sin ir más lejos, un lector no 
autorizado compatible EPC Gen2 en el rango de lectura del 
canal lector-etiqueta emitiendo constantemente peticiones de 
identificación, reduciría considerablemente la eficiencia de 
lectura de los lectores autorizados, retrasando los procesos de 
inventariado del sistema atacado. 

En el caso de tener acceso al canal etiqueta-lector, y 
haciendo uso de las vulnerabilidades especificadas al inicio de 
la Sección III se podría realizar un ataque del tipo tampering. 
Un lector no autorizado podría hacer uso del comando 
kill eliminando toda funcionalidad de cualquier etiqueta que 
entrara en su campo de lectura. 


IV. CONCLUSIÓN 


Los sistemas EPC Gen2 representan una de las tecnologías 
más pervasivas en el ámbito de las tecnologías de la 
información. La característica principal de la tecnología EPC 
Gen2 es el reducido precio de las etiquetas electrónicas 
(previsto por debajo de los 10 céntimos) lo que significa un 
compromiso entre coste y funcionalidad. Si a ello le añadimos 
que la comunicación entre etiquetas y lectores se realiza 
en un canal potencialmente inseguro y que cualquier lector 
compatible puede acceder a la comunicación de las etiquetas 
en su rango de lectura, la comunicación del sistema EPC Gen2 
padece el riesgo de sufrir ataques a la seguridad y privacidad 
de sus comunicaciones. 

El presente artículo plantea un modelo de adversario en 
función de las opciones y capacidades del adversario, y de 
las medidas de seguridad establecidas por el estándar EPC 
Gen2 (Sec. II). Se hace especial hincapié en la singularidad del 
modelo de comunicaciones del sistema EPC Gen2 en el que 
solo se establecen medidas de seguridad para los contenidos 
transmitidos por el canal lector-etiqueta. En la Sección III se 
hace una descripción detallada de las diferentes amenazas que 


puede padecer el sistema EPC Gen2, agrupadas en escuchas 
fraudulentas, suplantación de identidades, divulgación de 
información y denegación de servicio. Para un análisis más 
detallado sobre la evaluación de las amenazas relativas a la 
autenticidad, integridad y disponibilidad de la comunicación 
en el sistema EPC Gen2, puede consultarse [8]. 
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Resumen—La identificación por radio frecuencia permite 
identificar a un objeto de forma remota mediante ondas de 
radio. Esta característica ha sido utilizada en un gran número 
de aplicaciones. A partir de esta masiva implantación han 
surgido problemas de seguridad y privacidad. En este trabajo 
presentamos un protocolo seguro que protege la privacidad de 
los usuarios con un bajo coste computacional y que escala 
correctamente a diferencia de propuestas anteriores. 


I. INTRODUCCIÓN 


La tecnología RFID (Identificación por Radio Frecuencia) 
es un sistema que permite la identificación remota de un objeto 
mediante ondas de radio. Estos sistemas utilizan los siguientes 
elementos: lectores!, unos dispositivos llamados etiquetas o en 
inglés tags? que identifican a su portador mediante un número 
de serie que envían al lector reutilizando la energía de ondas 
de radio que este emite y un servidor conectado a una base 
de datos que es el encargado de dar ordenes al lector para 
comunicarse con las etiquetas. 

Actualmente, cualquier artículo es susceptible de incorpo- 
rar una etiqueta RFID siempre que su precio sea razonable 
respecto al del artículo y su ciclo de vida permita amortizarlo. 
Esta generalización esta dando lugar a muchos y novedosos 
usos de esta tecnología facilitando a sus usuarios un mayor 
control y una mayor reducción de costes en algunos procesos 
de producción sobretodo en algunos sectores como el textil o 
el automovilístico. 

Aun así, el hecho de utilizar esta tecnología, conlleva una 
serie de riesgos para la seguridad y la privacidad de quien 
la usa. Es por eso que es necesario desarrollar sistemas de 
seguridad para evitar el uso indebido de la información que 
estos sistemas manejan tal y como recomienda la Unión 
Europea en [1]. La parte más vulnerable del sistema, es la 
comunicación entre el lector y la etiqueta, donde un posible 
atacante podría obtener, con solo escuchar los mensajes entre 
estos dos elementos, el identificador de la etiqueta y en 
consecuencia podría identificar al objeto que la lleva o realizar 
un seguimiento de la posición o el estado en el que se 
encuentra de forma indebida. 


lLos lectores envían ondas de radio mediante una antena incorporada a 
estos, que permite la comunicación con las etiquetas. 

Habitualmente son pasivas, es decir que no disponen de fuente de 
alimentación propia. 


En el siguiente apartado, se analizan los diferentes requisitos 
que debe cumplir un protocolo de identificación RFID para 
ser seguro, a continuación en la sección III se describen los 
diferentes tipos de protocolos de identificación existentes en la 
actualidad para posteriormente presentar una nueva propuesta 
en la sección IV que es analizada en la sección V para finalizar 
con la sección VI donde se muestran las conclusiones. 


II. REQUISITOS DE LOS PROTOCOLOS RFID 


Antes de desarrollar un nuevo protocolo de identificación, 
es importante tener en cuenta una serie de requisitos que 
se deben cumplir. En los siguientes apartados se exponen 
varios aspectos referentes a la privacidad, la seguridad y el 
rendimiento de un protocolo de identificación RFID. 


IFA. Privacidad 


Una de las principales preocupaciones en los sistemas RFID 
es la privacidad. Estos sistemas utilizan las ondas de radio para 
comunicarse, por lo que cualquier atacante podría escuchar 
esta comunicación para obtener la identidad de un tag ya que 
se utiliza un canal de comunicación compartido. Teniendo en 
cuenta el trabajo de Song et al. en [2] podemos identificar dos 
cuestiones relativas a la privacidad: 

= Perfil del usuario: En un sistema RFID tradicional, 

cuando el lector pregunta al tag, este responde con 
su identificador único. Si este y otros identificadores 
correspondientes a un mismo usuario son obtenidos por 
un lector no autorizado, éste podría realizar un perfil 
del usuario. Además si los RFIDs contienen información 
sensible de una persona como por ejemplo un pasaporte 
o a una tarjeta médica ésta podría revelarse de forma no 
autorizada. 

= Seguimiento y/o localización: Si las respuestas de un 

mismo tag pueden diferenciarse de las de otras etiquetas, 
un atacante es capaz de obtener su localización mediante 
diversos lectores situados en puntos estratégicos. 


II-B. Seguridad 

A continuación se describen los ataques más comunes en 
sistemas REID. 

= Denegación de servicio: Un atacante puede interceptar 


los distintos mensajes entre el tag y el lector para impedir 
que se puedan comunicar. 
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= Seguimiento del tag: Si un tag se identifica siempre con 
el mismo identificador, un atacante podría ser capaz me- 
diante varios lectores de saber la localización aproximada 
de ese tag o de la persona que lo lleve. 

= Suplantación de los dispositivos: Un atacante puede 
hacerse pasar por una etiqueta aún sin conocer su in- 
formación y comunicarse con los lectores. Por ejemplo 
en un ataque de replay, un atacante puede escuchar la 
identificación de otro tag y puede retransmitir el mismo 
mensaje haciéndose pasar por el tag anterior. De modo 
parecido, si un atacante conoce el estado interno de 
una etiqueta, éste es capaz de hacerse pasar por un 
servidor válido para la etiqueta. Si combinamos estas dos 
situaciones, nos encontramos con un ataque “Man in the 
middle” [3]. 


Il-C. Rendimiento 


Debido a las limitaciones tecnológicas de los tags RFID hay 
que tener en cuenta los siguientes requisitos para elaborar un 
protocolo de identificación. 

= Minimización de la capacidad de almacenaje: El 

volumen de datos guardados en el tag debe ser mínimo 
debido a la limitación de memoria que tienen los tags. 
= Minimización de la capacidad de cálculo: La com- 
putación del lado del tag debe ser mínima ya que no 
disponemos de mucha energía al ser estos pasivos. 
= Compresión de la capacidad de comunicación: El 
volumen de datos que puede transmitir cada tag por 
segundo esta limitado por el ancho de banda disponible 
para tags RFID [4], [5]. 

= Escalabilidad: El servidor debe ser capaz de identificar 
una gran cantidad de tags distintos utilizando el mismo 
canal de radio. El hecho de utilizar una búsqueda exhaus- 
tiva en su base de datos puede ralentizar la identificación. 


TI. ESTADO DEL ARTE 


Existen varios tipos de protocolos de identificación segura 
para sistemas RFID. En esta sección se describen dos tipos 
de protocolos basados en criptografia de clave simétrica que a 
su vez son los más significativos y utilizados en la actualidad. 
Este problema se podria abordar mediante criptografia de clave 
asimétrica utilizando por ejemplo curvas elípticas como en [6], 
pero las capacidades de cálculo de los tags actuales son muy 
limitadas para implementar este tipo de protocolos. 


HTA. Protocolos basados en Hash 


Este tipo de protocolos basan su seguridad en las funciones 
hash unidireccionales, donde a partir del resultado de una 
función hash resulta computacionalmente inviable obtener su 
entrada. El primer protocolo basado en hash fue el propuesto 
por Rivest, Weis, Sarma y Engels en 2003 [7], donde se 
proponen los hash locks deterministas. Juels en 2006 [8] 
propuso uno de los protocolos más conocidos en este ámbito, 
los Hash Locks aleatorios. En este protocolo tanto el lector 
como el tag generan un número aleatorio que el tag concatena 


junto a su identificador para generar un hash. Este hash es 
enviado posteriormente al servidor que busca el identificador 
que coincida con el resultado de la función hash. El mayor 
problema de este método es la escalabilidad del sistema [9] 
ya que es necesario realizar una búsqueda exhaustiva para cada 
uno de los identificadores hasta encontrar el adecuado. En el 
mismo sentido trabaja el protocolo OSK [5] que refresca el 
identificador del tag en cada identificación mediante funciones 
hash para que éste no pueda ser rastreado. OSK tampoco 
resulta escalable, por lo que Avoine y Oechslin propusieron 
una mejora de este protocolo en [11] para mejorar ésta 
caraterística. Aún así, este tipo de protocolos resultan muy 
eficientes del lado del cliente (en nuestro caso el tag), ya que 
las operaciones que debe realizar éste son mínimas lo qual es 
muy importante debido a la poca capacidad de cálculo de que 
disponen las etiquetas RFID actuales. 


HFB. Protocolos basados en el sincronismo 


Estos protocolos surgen debido a la falta de escalabilidad 
de los protocolos basados en hash. Aunque varios protocolos 
de este tipo también están basados en hash, tienen la partic- 
ularidad de utilizar el tiempo de respuesta o un estado de 
sincronismo entre el lector y el tag. Esto permite en caso 
de que los dos dispositivos estén sincronizados, realizar una 
identificación de forma rápida y segura, pero pueden presentar 
varios problemas cuando un atacante desincroniza los dos 
dispositivos. Aún así, este tipo de protocolos son escalables 
en estado de sincronismo, pero presentan problemas cuando 
se pierde el sincronismo. Uno de estos protocolos, YA-TRAP 
[10], utiliza una serie de estados de tiempo [To, ..., T max] que 
protegen la identidad del tag. 

Otro protocolo de este tipo es el propuesto en [12], donde 
los autores utilizan el estado de sincronismo para realizar una 
identificación rápida, mientras que utilizan hash locks para 
identificar los tags cuando estos se encuentran desincroniza- 
dos. Son comunes los ataques de desincronización en este tipo 
de protocolos tal y como se indica en [13]. 


IV. NUESTRA PROPUESTA 


Este nuevo protocolo consta de tres fases, la fase de ini- 
cialización, la fase de identificación y finalmente la fase de 
actualización que se ejecuta después de cada identificación 
satisfactoria. 

Los objetivos de nuestra propuesta son mejorar la escalabil- 
idad de los protocolos de identificación, y que un atacante no 
pueda diferenciar si los dispositivos están sincronizados o no. 
Esto se consigue enviando los mismos bits de información 
en las dos fases de identificación (principal y secundaria). 
Además estos bits resultan aleatorios para el atacante en todo 
momento. 

En el cuadro I se muestra la notación utilizada para la 
descripción del nuevo protocolo de identificación. 


218 


id Identificador del Tag 


R Lector 
PP Tag 
Pi Número aleatorio ¿ 
h(O Función de hash unidireccional 
O) Función de hash con clave (HMAC) 
ks Clave secreta del lector 
PRNG Generador de números pseudo-aleatorios 
SYNC Estado de sincronización 
C; Secuencia de bits pseudo-aleatorios 
S Secuencia de bits pseudo-aleatorios 
mi Mensaje de actualización ¿ 
ks hía(r1) realizado d veces 
ll Operador de concatenación 
e Operador de XOR 
Cuadro 1 
NOTACIÓN EMPLEADA EN EL PROTOCOLO 
Tabla k hlglri) ri  hialri) ri  hps(id) id 
ki 
ka 
k3 
kmax [| 


Cuadro II 
TABLA DE VALORES BD 


IV-A. Entorno del sistema 


Para la implementación de este protocolo es necesario 
disponer de un servidor con su correspondiente base de datos, 
y un lector el cual transmita la información obtenida de los 
diversos tags que haya en el sistema. 

Para cada tag, el sistema dispondrá de un registro como el 
del cuadro II. 

Se dispondrá del identificador ¿id y el hash con clave del 
mismo hgs(id), así como de los valores aleatorios rj junto 
con su hash con clave correspondiente h;a(r1). En este caso 
guardaremos el r, actual y el siguiente r/. De esta manera se 
podrá diferenciar el estado de sincronismo del sistema. 

Para añadir un grado más de seguridad en el sistema, el hash 
del identificador de cada tag es el resultado de un hash con 
clave (HMAC). ks es la clave que se utiliza en esta operación 
y que tan solo conocen los lectores autorizados. 


IV-B. Fase de inicialización 


En esta primera fase, el servidor envía a través del lector la 
información siguiente: hy.,(¿d), 71, hia(r,). Esta información 
será la utilizada por el tag para realizar la fase de autenticación. 
El traspaso de esta información se realiza a través de una canal 
seguro que garantiza la confidencialidad de los datos en el 
sistema. 


IV-C. Fase de identificación principal 


En esta segunda fase, ver cuadro Ill, el lector envía 
un número aleatorio rg al tag, mientras este responde 
con la información siguiente: h;g(r1),Co,r2. Donde Co = 
PRNG(rillro) y ra es un número aleatorio generado por 
el tag. Cuando el lector recibe esta información la envía al 


servidor para que calcule ri, y el ¿d. Además, el servidor 
ha de ser capaz de verificar la secuencia Cy que el tag ha 
generado previamente para asegurar que este es auténtico, 
evitando así una suplantación de identidad o un ataque de 
replay. Finalmente el tag después de enviar todos los datos 
pasa a estar desincronizado (SY NC! = 0) hasta finalizar la 
fase de actualización. 


IV-D. Fase de actualización 


En esta tercera fase, el servidor realiza los siguientes cál- 
culos: 


mo = 1 ||hia(r,) 
a = hys(0d)||ra 
mi = ha (Mo) 
ma = mo||m, 
S = PRNG(hs(id)lIrx) 
C¡=m20 8 
Posteriormente envía C1 al tag para que este realice las 
Operaciones siguientes: 
S' = PRNG(has(id)||r:) 
m3=C,0 5 
o = hys(id)||r2 
mi = ha» (mg) 
ri =14,,hia(r1) = hialr,) 


SYNC =1 


IV-E. Fase de identificación secundaria 


En el caso que C¡ no se reciba correctamente o sea incor- 
recto, y por lo tanto el estado de sincronización es SYNC =0 
el tag seguirá el siguiente protocolo: 


1. El lector enviará un rg al tag. 

2. El tag generará un nuevo ra, y realizará los siguientes 
cálculos: para 4 dentro de (1,..., MAX) y siendo ko = 
hialr1), 


9 =h(r2) mod MAX 
ks = Pr. (ia) (Ko-1) 


Co = PRNG(h,., (ra||ro)) 
y enviará k;, Co, ra al lector 


1. El lector retransmitirá la información al server que en 
primer lugar buscará el valor k;5 en la base de datos. Si 
este valor no se encuentra, se calculará el valor de ó y 
obtendrá mediante kg el identificador correspondiente al 
tag que será verificado mediante la secuencia Co. 

2. Una vez identificado el tag, el lector volverá a iniciar la 
fase de actualización. 
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Server Reader 


ro € R[0, 1P* 


hialr1), Co, r2,r0 
A CI 
Busca el valor h;g(r1) 
Verificar Co 


mo =r4IIha(r%) 

a = hys(id)||r2 

mi =hal(mo) 

ma = my||ma 
PRNG(hgs(id)||r1)=S 
Ci=m205S 


Fase de inicialización (mediante canal seguro) 


Fase de identificación principal 


Fase de actualización 


Tag 
hys (id), 11, hia(ri) 
ílIlI  €iÉKÉ— 
ro 
IlIlII  CííKíK> 
ra € RÍ0, 1)* 
Co = PRNG[(rillro) 
SYNC=0 


hia(r1), Co, r2 


EOS 


C1 


sg = PRNG(hps(id)||r1) 
m3=C105S 
al = Rks (id)|[r2 

? 
ma Í has (mo) ) 
r1="3, hia(r1) = hia(r,) 


SYNC =1 
Fase de identificación secundaria 
ro € RÍO, 1)* e 
E -— — 
raeR(0, 1])* 
9 =h(r2)mod MAX 
ks = har. (ia) (1) 
Co = PRNG(h,, (ra]|ro)) 
ks, Co, r2 ks, Co, ra 
 _AAA<AAAAAA< == € —_AA<AAA<K<X> 
Si el valor k5 no se encuentra en la BD 
$ =h(r2) mod MAX 
Cálculo de ¿d mediante k5 
Verificar Co 
Fase de actualización 
Cuadro HI 


PROTOCOLO DE IDENTIFICACIÓN SEGURO 


IV-F. Selección del parámetro MAX 


El parámetro MAX utilizado influye en el protocolo pro- 
porcionado en tres conceptos: 


= Espacio de memoria: Considerando n tags, en la BD 
tenemos una tabla de MAX valores asociados a cada 
tag. Cada uno de estos valores equivale a la salida de 
una función hash. Asumiendo la utilización de la función 
de hash SHA-1 [14], cada uno de estos valores ocupará 
160 bits. Como resultado, los requerimientos de memoria 
para este concepto son: n- MAX - 160 bits 

= Coste computacional: La fase de actualización secundaria 
del protocolo requiere localizar k5 en la tabla de MAX 
posiciones asociada a cada tag. Una vez localizado, el 
lector conoce el ¿d del tag correspondiente. El cálculo de 
Ó es previo a dicha búsqueda y por lo tanto la localización 
de kg dentro de la tabla de MAX posiciones se considera 
un acceso directo (coste O(1)). El coste para localizar el 


tag que contiene k¿ en su tabla es O(1) debido a que 
sólo debemos saber si éste elemento se encuentra o no 
en nuestra base de datos. Por lo tanto, el sistema escala 
correctamente para grandes valores de n (número de tags) 

= Seguridad: Tal como se justificará en la sección V 
referente al análisis de seguridad, cuanto mayor es el 
valor de MAX mayor es la seguridad proporcionada por 
el protocolo de identificación propuesto. 


Como conclusión, el valor de MAX a elegir dependerá prin- 
cipalmente del espacio de memoria disponible y del tiempo P 
en que un atacante es capaz de obtener los MAX valores 
de la tabla k, para el cálculo de este valor se toma una 
referencia de 200 ms por identificación. Aunque los requisitos 
de memoria del sistema son elevados, podemos considerar 
que este recurso es actualmente asequible y por lo tanto 
dicho requisito es aceptable. En cuanto al tiempo /P, éste 
dependerá del nivel de seguridad que se desee en el sistema. 
Debido a la potencia actual de los procesadores consideramos 
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MAX Tags Espacioendisco Tiempo PB 
100 100 0,024 Gb 20 s 
1.000 1.000 2,4 Gb 200 s 
10.000 10.000 240 Gb 2000 s 
100.000 100.000 24 Tb 33h 
1.000.000 1.000.000 2400 Tb 55,5 h 
Cuadro IV 


TABLA DE VALORES MAX 


que el tiempo de respuesta al usuario tampoco será un gran 
inconveniente para el sistema. En la tabla IV podemos observar 
diversos resultados de la aplicación de valores de MAX y de 
varios valores de Tags presentes en cada sistema. Fijándonos 
principalmente en la columna de Tiempo PB, podemos observar 
como para valores elevados de MAX, el tiempo necesario 
para obtener todos los registros de la tabla k, es de suficiente 
envergadura para soportar ataques eventuales. Aun así, el 
precio a pagar por tener un sistema más seguro es el espacio 
en disco. 


V. ANÁLISIS 


El protocolo dispone de las siguientes propiedades de pri- 
vacidad y seguridad: 


= Información privada del tag: Se garantiza la integridad 
de la información del tag ya que éste no conoce su propio 
identificador. Tan sólo conoce hy.s(¿d) por lo que si un 
atacante consigue averiguar el contenido del tag, no será 
capaz de diferenciar su verdadero identificador. 

= Localización y seguimiento del tag: La privacidad de 
la localización se garantiza ya que en cada nueva identi- 
ficación, los datos que envía el tag son siempre distintos 
a los que envió anteriormente ya que hia(r;i), Co, ra 
se actualizan en cada identificación. En el caso que el 
lector y el tag no estén sincronizados, son kys, Cy, ra los 
elementos que varían en cada identificación. La proba- 
bilidad que h;g(r,) se repita en estado de sincronismo 
es de em mientras que la de kj es de ST en MAX 
identificaciones secundarias consecutivas. 

= Suplantación del tag: No es posible suplantar al 
tag ya que un atacante no conoce los valores 
hys(id), 11, hia(r1) con los que se ha inicializado al tag 
mediante un canal de comunicación seguro y por lo tanto 
el lector detectaría que no se trata de un tag legítimo y 
lo rechizaría. 

= Suplantación del servidor: Análogamente a el aparta- 
do de suplantación del tag, no es posible suplantar al 
servidor a menos que se conozca su base de datos por 
completo. Suponemos que esta base de datos se encuentra 
en un entorno seguro. 

= Ataques de replay: Este tipo de ataques no es posible 
en este protocolo debido a que en cada identificación 
cada una de las partes (tag y servidor) proporcionan un 


nuevo valor obtenido de forma aleatoria. Si un atacante 
reenvía al servidor un mensaje que haya capturado con 
anterioridad, éste sólo lo acepta si el mensaje capturado 
tiene el mismo valor rg que le ha enviado previamente. 
Esto mismo ocurre en el caso del tag, pero con el 
valor r2. Los valores aleatorios rg y r2 se generan en 
cada dispositivo y la probabilidad que se repitan es 
practicamente nula en un espacio de tiempo corto. En este 
sentido el valor de h;¿(r,) varía en cada identificación 
principal, mientras que en el caso de la identificación 
secundaria, es el valor k; el que varía hasta MAX veces. 

= Ataques de denegación de servicio: Este tipo de ataques 
sí se pueden dar. Aun así podemos entender que un 
atacante no denegará el servicio para siempre y por 
lo tanto es un tipo de ataque que puede impedir la 
identificación de tags pero en ningún caso comporta un 
riesgo de seguridad en el sistema. Además en el caso 
que se de este ataque, el sistema no queda bloqueado 
y sigue funcionando correctamente en identificaciones 
posteriores. El problema de este tipo de ataque está en 
el hecho que una vez agotados los elementos de la tabla 
k el sistema volverá a repetir valores. Aún así si la tabla 
es suficientemente grande el tiempo en obtener todos los 
valores puede resultar elevado tal y como se discute en 
la sección IV-F. 


VI. CONCLUSIONES 


Después del estudio realizado y de presentar la nueva 
propuesta, podemos concluir que este nuevo protocolo re- 
sulta más escalable que los sistemas basados en hash o las 
propuestas basadas en sincronismo. Haciendo uso de las dos 
tecnologías, se consigue obtener un coste O(1) para cualquier 
identificación. Además, los mensajes enviados en las dos fases 
de actualización, no permiten a un atacante saber si el sistema 
esta sincronizado o desincronizado. A este aspecto hay que 
añadir el hecho que el propio tag no conoce su identificador 
por lo que si un atacante obtiene los valores con los que ha 
sido inicializado un tag, no conocerá realmente su identificador 
en la Base de Datos del sistema. 

El aspecto más controvertido del sistema es el espacio 
utilizado en disco, ya que para un orden de millones de tags, 
nuestra base de datos se dispara a valores de Terabytes. Aún 
así este tipo de valores ya son muy comunes en el mercado hoy 
en día y a un precio razonable, por lo que podremos asumir 
el coste que supone. 
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Abstract—Desde hace algunos años, la criptografía basada en 
identidad se ha considerado como una de las propuestas más 
razonables para los entornos de redes vehiculares (VANETs). 
Por otra parte, los sistemas que emplean la identificación 
por radiofrecuencia (RFID) también han sido objetivos de la 
criptografía basada en identidad. Sin embargo, la combinación 
de estas dos tecnologías, que permite desarrollar aplicaciones 
muy interesantes para la seguridad vial, presenta características 
que dificultan la aplicación de las técnicas criptográficas que se 
pueden emplear de manera independiente en cada una de ellas. 
En concreto, las arquitecturas en las que el lector se encuentra 
localizado en el vehículo y los tags en la carretera presentan 
unas importantes limitaciones derivadas de la velocidad de 
los vehículos y de las frecuentes pérdidas de conectividad. 
En este trabajo se describe este escenario y se presentan los 
requisitos de seguridad. Asimismo, se propone un esquema 
general considerando tanto los aspectos criptográficos como los 
de implementación. 


I. INTRODUCCIÓN 


Las redes ad hoc vehiculares (VANETs) se pueden consid- 
erar actualmente como una nueva generación de redes orien- 
tadas a mejorar la seguridad vial y el confort en la conducción. 
Estas redes permiten la comunicación entre usuarios móviles 
(vehículos) sin necesidad de acudir a una infraestructura fija 
que dé soporte a las comunicaciones. El protocolo empleado 
en estas comunicaciones es el protocolo inalámbrico IEEE 
802.11p, en el que los vehículos deben colaborar en las 
tareas de red para conseguir unos mecanismos eficientes de 
enrutamiento y transmisión, debido a la topología dinámica 
de la VANET. 

También es habitual la utilización de infraestructuras fijas de 
apoyo con el fin de mejorar las prestaciones de la red. De esta 
forma se pueden diferenciar varios tipos de comunicaciones: 
vehículo a vehículo (V2V) en los casos en los que no se 
utiliza la infraestructura fija, vehículo a infraestructura (V2I) 
e infraestructura a vehículo (12V). 

Esta infraestructura no sólo mejora la eficiencia de la red 
sino que permite el desarrollo de aplicaciones orientadas a 
la mejora de la Seguridad Vial puesto que los vehículos 
pueden recibir información sobre el estado del tráfico, y la 
infrestructura puede obtener información directamente de los 
vehículos que están circulando [13]. 

En un entorno VANETSs se distinguen dos tipos de infor- 
mación que contribuyen a la mejora de la seguridad vial. En 
primer lugar, la información originada en los demás vehículos, 
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relacionada habitualmente con la congestión del tráfico o 
con alertas de accidentes. Esta información se transmite gen- 
eralmente en modo broadcast [7], [27]. El segundo tipo de 
información se refiere a la que proviene del entorno, es decir, a 
la que proporcionan las señales de tráfico, límites de velocidad, 
peajes o semáforos. 

En este sentido, son cada vez más frecuentes las propuestas 
para dotar al vehículo de sensores que sean capaces de captar 
de un modo autónomo información sobre su entorno que 
utilizarán para mejorar su propia conducción y que compar- 
tirán con el resto de vehículos a través de enlaces V2V o a 
través de la infraestructura con enlaces V2I e 12V. Algunas de 
esas propuestas utilizan técnicas de procesado de imagen para 
reconocer las señales de tráfico a partir de una imagen tomada 
por una cámara a bordo del vehículo [18]. 

Una tecnología que se emplea en las redes vehiculares 
para que los vehículos se comuniquen con su entorno más 
cercano es la identificación por radiofrecuencia (RFID). Estos 
sistemas permiten a un lector detectar la presencia de unas 
etiquetas (tags) y autenticarlas utilizando frecuencias que 
pueden estar en banda LF, HF o UHF, principalmente. La 
ventaja de estos sistemas es que los tags pueden ser pasivos, 
es decir, no necesitan alimentación. La energía necesaria para 
transmitir una respuesta al lector la obtienen directamente del 
campo creado por éste cuando se encuentra a una determinada 
distancia. Como característica genérica de estos tags hay que 
destacar su bajo precio, asociado a una limitada capacidad de 
almacenamiento, y sobre todo, de computación [12]. 

El modo más sencillo de integrar la tecnología RFID en 
una VANET consiste en colocar un tag en cada vehículo y 
uno o varios lectores en lugares estratégicos de la carretera. 
Este esquema permite implementar comunicaciones V21 con 
un coste mínimo. Actualmente, casi todas las aplicaciones de 
la tecnología RFID a las VANETs siguen este esquema, como 
por ejemplo, el control del peaje [22]. La Unión Europea está 
trabajando en un sistema RFID de seguimiento para controlar 
las violaciones de tráfico [1], como aplicación directa de las 
matrículas electrónicas (Electronic License Plate) [25]. Otras 
propuestas describen sistemas automáticos para el pago en los 
aparcamientos y sistemas de prioridad para los semáforos [16]. 

Sin embargo, la tecnología RFID se puede integrar como 
parte de los sistemas de adquisición de datos compuestos, 
principalmente, por sensores a bordo del vehículo. Como 
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los sistemas RFID no sólo permiten identificar objetos, sino 
también autenticarlos, suponen una alternativa interesante para 
establecer comunicaciones del tipo 12V. Por una parte, la 
RFID no incrementa significativamente el coste de gestión 
de la VANET, ya que los tags son dispositivos pasivos de 
bajo coste. Por tanto, se puede desplegar una gran cantidad 
de tags para complementar a la señalización de tráfico tradi- 
cional. La información obtenida a partir de los tags tiene 
siginificado local debido a la limitación en las distancias de 
lectura. Además, estos sistemas RFID pueden funcionar en 
condiciones de climatología adeversa, con visibilidad reducida 
o nula. Esto permite desarrollar sistemas que informan de la 
proximidad de intersecciones, de curvas peligrosas, de que se 
viaja en sentido contrario, etc. 

En las siguientes secciones se describe la arquitectura de 
los sistemas RFID con lectores a bordo de los vehículos y 
los requisitos de seguridad que deben satisfacer. También se 
describen los criptosistemas más adecuados para este nuevo 
escenario que se plantea, concluyendo con unas notas sobre 
la viabilidad de aplicar criptosistemas basados en identidad. 


II. ARQUITECTURA RFID-VANET PARA MEJORAR LA 
SEGURIDAD VIAL 


La integración de los sistemas RFID en VANETSs se puede 
conseguir a través de dos arquitecturas conceptualmente op- 
uestas. Por una parte, la arquitectura tag a bordo-lector en 
carretera que responde al mismo esquema de los sistemas 
RFID tradicionales que se aplican en otros ámbitos, y por otra 
la arquitectura lector a bordo- tag en carretera. En ambos 
casos, es necesario utilizar tecnología UHF, debido a las 
distancias de lectura necesarias. 

En la arquitectura tag a bordo-lector en carretera los tags 
tienen movilidad mientras que los lectores permanecen fijos 
en posiciones determinadas. Esta situación permite que los 
lectores se puedan conectar con servidores de apoyo que 
aumenten la capacidad de cálculo o almacenamiento, o que 
faciliten la funcionalidad requerida en cada momento. En 
consecuencia, los protocolos de autenticación que se deben 
aplicar son esencialmente los que se han aplicado hasta ahora. 

En cambio, la arquitectura opuesta, denominada lector a 
bordo- tag en carretera, presenta mayores limitaciones o 
restricciones que dificultan su desarrollo y sobre todo la im- 
plementación de protocolos seguros. Una de estas limitaciones 
queda determinada, fundamentalemnte, por la velocidad a la 
que se desplazan los vehículos, y en consecuencia, los lectores. 
Los tags, sin embargo, están colocados en posiciones fijas 
a lo largo de la carretera proporcionando información con 
significado local. La otra gran limitación es la pérdida de 
conectividad que puede sufrir el vehículo durante la marcha 
por carretera. Esto impide la conexión con servidores externos 
lo que dificulta enormemente las tareas de autenticación de los 
tags. 

Existen algunas iniciativas que proponen la utilización 
de esta arquitectura lector a bordo- tag en carretera con 
diversos objetivos [8], [19], [20], [21]. En [20] Pentila et 
al proponen esta arquitectura para controlar el movimiento 


de unos robots, es decir, para proporcionar a los robots un 
sistema de conducción autónoma. Tras realizar pruebas en 
laboratorio, los autores concluyeron que la máxima velocidad 
a la que podía funcionar su sistema era de 40 Km/h, lo 
cual es claramente insuficiente para una VANET. Más tarde, 
Chon et al [8] proponen esta arquitectura para mejorar el 
sistema de posicionamiento GPS de los vehículos. En esta 
ocasión los autores aseguran que la máxima velocidad a la 
que puede funcionar el sistema es 165 Km/h extrapolando 
unos cálculos teóricos a partir de unos resultados de labora- 
torio. Sin embargo, no se han realizado experimentos que lo 
confirmen. En 2004, una empresa española que participa en el 
proyecto europeo eSafety [11] lanza una solución comercial 
para VANETs denominada RBS (road beacon system) [21]. 
Desgraciadamente no existen datos sobre rangos de velocidad 
o distancia de trabajo de este sistema. Recientemente, Lee et 
al [16] han instalado un sistema experimental en un vehículo 
y han evaluado su funcionamiento. Los resultados establecen 
que la máxima velocidad de funcionamiento es 100 Km/h con 
una alta tasa de error en las lecturas. 

Aunque estos resultados permiten la utilización del sistema 
en áreas de velocidad reducida, por ejemplo, en el caso urbano 
de las ciudades, es necesario seguir investigando, puesto que 
los datos obtenidos hasta la fecha depende en gran medida de 
las características particulares de los tags y lectores emplea- 
dos, que determinan las tasas de transferencias de datos, las 
distancias máximas de lectura, los tiempos de activación de 
los tags, etc. 

En cualquier caso, y con independencia de las velocidades 
máximas obtenidas, ninguna de las propuestas existentes tiene 
en cuenta los requisitos de seguridad, tan necesarios en una 
implementación orientada a la Seguridad Vial. En la siguiente 
sección se establecen estos requisitos de seguridad. 


III. REQUISITOS DE SEGURIDAD DE LOS SISTEMAS 
RFID-VANET 


Los requisitos de seguridad de los sistemas RFID-VANET 
con arquitecturas tag a bordo-lector en carretera son los 
mismos que los de cualquier sistema RFID tradicional. Esta es 
la principal razón por la que las aplicaciones RFID que existen 
actualmente, relacionandas con el tráfico de vehículos, respon- 
den únicamente a esta arquitectura. A pesar de ello, muchas 
de estas aplicaciones no aplican mecanismos de seguridad o 
presentan un bajo nivel de seguridad, como es el caso de los 
sistemas de peaje [22]. 

Aunque se han presentado numerosas propuestas para mejo- 
rar la seguridad de los sistemas RFID en banda UHF [6], no 
se están utilizando porque las aplicaciones reales continuan 
utilizando el estándar EPC [10], cuya seguridad ha sido 
comprometida desde hace tiempo. Esto hace que en los casos 
en los que la seguridad es un requisito real y necesario, se 
utilicen protocolos propietarios. 

Los requisitos de seguridad para los sistemas RFID-VANET 
con arquitecturas lector a bordo-tag en carretera son los 
siguientes: 
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Confidencialidad. No es necesario que la comunicación 
entre el lector y los tags tenga que ser cifrada. Dado que los 
datos obtenidos de los tags proporcionan información sobre el 
estado de la carretera, se considera información pública que 
debería estar disponible para todos los vehículos. Como es 
lógico, se mantiene el criterio general aplicado al resto de 
aplicaciones de seguridad vial que se implementan en una 
VANET [13], [26]. 

Trazabilidad. Debido a que los tags están colocados en 
lugares fijos de la carretera, la trazabilidad no supone un 
problema. Este hecho simplifica notablemente los protocolos 
de identificación y autenticación. 

Autenticación. Como en cualquiera otra arquitectura RFID, 
la autenticación es la pieza fundamental del sistema. Por tanto, 
es imprescindible. En la arquitectura RFID-VANET que se 
analiza en este trabajo, el principal riesgo reside en la posi- 
bilidad de que un atacante falsifique algún tag y lo introduzca 
en el sistema generando falsas informaciones a los vehículos 
que las detectan, provocando desorientación y desconcierto 
en los conductores, e incluso accidentes. En consecuencia, 
se necesita un esquema robusto de autenticación, que resista 
posibles ataques por repetición y que detecte la clonación de 
tags. 

No-repudio. Este servicio de seguridad no es un requisito 
para este tipo de aplicaciones. Sin embargo, si el esquema de 
autenticación empleado es suficientemente seguro, se podría 
implementar un servicio de no-repudio que permita demostrar 
a los conductores que estuvieron conduciendo por una deter- 
minada carretera, a una cierta hora de un día concreto. 

Disponibilidad. Este es siempre un requisito de los sistemas 
que utilizan la tecnología RFID. Sin embargo, en la arquitec- 
tura que estamos analizando no es imprescindible, puesto que 
la información proporcionada por los tags no es la única que 
se puede obtener desde el vehículo. Además, la información 
obtenida a través de los tags debe ser considerada en todo 
momento como complementaria y el objetivo es ayudar al 
conductor a tomar una determinada decisión. En ningún caso 
se pretende que la conducción del vehículo dependa exclusi- 
vamente de los datos recopilados por el sistema RFID. 

Todos estos requisitos de seguridad simplifican aparente- 
mente los esquemas de identificación a utilizar puesto que 
únicamente la autenticación es imprescindible. Además, los 
algoritmos de anticolisión no resultan necesarios ya que los 
tags serán siempre detectados de uno en uno [12]. 

Sin embargo, los actuales protocolos de autenticación en 
RFID no se pueden aplicar directamente debido a una serie de 
limitaciones: la velocidad a la que circulan los vehículos, las 
distancias de lectura y la pérdida de conectividad del vehículo 
con redes externas. Además, aunque la comunicación entre 
tag y lector tiene una duración muy corta en el tiempo, es 
importante resaltar que cualquier atacante puede acercarse a 
uno de los tags ubicados en la carretera e interrogarlo por 
tiempo indefinido. 

Todos estos requisitos y limitaciones determinan no sólo 
el tipo de tag a utilizar sino también el sistema de seguridad. 
Así pues, los tags RFID más simples, conocidos habitualmente 


como tags básicos, y que se emplean para identificación sin 
autenticación, no son aptos para estas arquitecturas puesto 
que no incorporan servicio de seguridad alguno. Estos tags 
permitirían a cualquier atacante no experto falsificar los tags 
sin más que leer desde un vehículo el identificador que emiten 
como respuesta. 

Los tags que incorporan funciones criptográficas se pueden 
dividir en dos categorías [15]: tags de clave simétrica y tags 
de clave asimétrica. 

Los primeros no resultan adecuados debido a la enorme 
complejidad de la gestión de claves. No resulta viable que 
todos los vehículos conozcan a priori las claves de todos los 
tags distribuidos por todas las carreteras, ni los tags pueden 
conocer las claves de todos los vehículos. La razón, además del 
elevado número de tags, es el hecho de que los vehículos no 
disponen de una conexión permanente que les permita acceder 
a un servidor externo. 

Los tags de clave asimétrica podrían ser una solución ya 
que el lector a bordo del vehículo podría verificar mediante 
la correpondiente clave pública las firmas generadas por los 
tags. Es decir, si todos los tags tienen asociado un par de 
claves (pública y privada), el contenido de los tags podría 
estar protegido mediante la firma realizada con la correspon- 
diente clave privada. El gran inconveniente es la limitada 
capacidad computacional de los tags, que hace inviable una 
implementación de estos algoritmos, junto con la reducida 
capacidad de almacenamiento. Nótese que para verificar la 
firma de un tag sería necesario leer el certificado de su clave 
pública, y obtener posteriormente la firma de algún dato que 
le envíe el lector. De otra manera, si el tag devuelve siempre 
el mismo mensaje firmado, se podría clonar el contenido 
incluyendo la firma y crear tags con el mismo contenido. 

Dentro de esta categoría de criptosistemas asimétricos hay 
un tipo especial de sistema conocido como esquema de cifrado 
o de firma basado en identidad, diseñado para reducir la com- 
plejidad global utilizando la propia identidad de los usuarios 
(p.e. una dirección de correo electrónico) como clave pública, 
en lugar de los certificados emitidos por una autoridad de 
certificación [2]. 

La implemenatación de estos sistemas requiere la existencia 
de un servidor central de confianza PKG. Este servidor genera 
su clave privada (maestra) y su clave pública. A continuación 
el PKG genera la clave privada de cada usuario (bajo petición 
de cada uno) asociada con la identidad del propio usuario. En 
el caso de los sistemas RFID, esta clave privada puede ser 
incorporada a cada tag y a cada lector antes del despliegue 
del sistema. 

La principal ventaja de estos sistemas reside en el modo en 
que un usuario obtiene la clave pública de otro usuario. En los 
sistemas asimétricos tradicionales las claves públicas deben 
ser recuperadas de algún repositorio público. En el caso de 
los sistemas basados en identidad, un usuario puede generar 
la clave pública de otro a partir de los datos identificativos 
de éste último. Por tanto, no es necesario establecer ninguna 
conexión para verificar las firmas de los tags. Por todo ello, los 
sistemas basados en identidad parecen los más adecuados para 
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proporcionar seguridad en las arquitecturas RFID-VANET con 
lectores a bordo y tags en carretera. 


TV. ESQUEMAS BASADOS EN IDENTIDAD PARA MEJORAR 
LA SEGURIDAD VIAL 


La criptografía basada en identidad fue introducida por 
Shamir en 1984 [23] con un esquema de firma basada en 
identidad utilizando el algoritmo RSA. En 2001, Boneh y 
Franklin [3] y Cocks [5] presentaron por vez primera sendos 
esquemas de cifrado basado en identidad. Desde entonces el 
interés por estos esquemas ha crecido notablemente. 

La criptografía basada en identidad ha sido propuesta en 
numerosas ocasiones para los protocolos seguros en VANET:s. 
Sin embargo, la primera propuesta para aplicarla en sistemas 
RFID aparece en 2007. Más concretamente, en [14] se propone 
la utilización del esquema de firmas cortas de Boneh et al 
[4] para verificar la autenticidad del contenido de los tags de 
un sistema RFID de HF que utilizaba etiquetas ¡CODE de 
Phillips. 

El algoritmo propuesto en [14] consiste en utilizar la iden- 
tificación del tag como clave pública. El PKG correspondiente 
genera una clave privada con la que se firma un mensaje que 
también se almacena en el tag. Por tanto, cuando un lector 
interroga a un tag, obtiene la identificación del tag, el mensaje 
que se ha firmado y la firma para que se pueda verificar. 

En 2008, Liang y Rong [17], proponen la utilización de crip- 
tografía basada en identidad para implementar un protocolo de 
autenticación mutua entre tag y lector, en el que se firman y 
se cifran datos. Sin embargo, aunque no especifica la banda de 
frecuencias de trabajo (LF, HF o UHF), este esquema supone 
que los tags conocen a priori las identidades de los lectores, 
lo que hace inviable su aplicación en arquitecturas lector a 
bordo- tag en carretera para VANETS. 

Todas las propuestas existentes se han definido sobre ar- 
quitecturas RFID tradicionales, que no tienen en cuenta las 
limitaciones de la velocidad y falta de conectividad de los 
vehículos, y en algunos casos diseñadas para funcionar fuera 
de la banda de UHF. 

Los datos experimentales de [16] obtenidos en pruebas 
reales con vehículos, indican que la velocidad máxima de 
trabajo está limitada a unos 100 Km/h. Estos datos fueron 
obtenidos utilizando el chip EM4222 [9] que funciona en 
banda UHF, con una capacidad para transmitir 64 bits a 256 
Kbps. Además como este chip implementa procedimientos 
anticolisión, el tag espera un tiempo aleatorio antes de re- 
sponder. El tiempo máximo de espera es de unos 62.5 msg. 
Este hecho es uno de los principales factores en la limitación 
de la velocidad. 

Tomando estos datos como referencia, y dado que las 
firmas cortas empleadas en [14] son de 160 bits, se puede 
establecer el siguiente esquema de firma basado en identidad 
para los sistemas RFID con arquitectura lector a bordo- tag 
en carretera, en el que se aplicará el esquema de firmas cortas 
de Boneh [4]. 

Inicialización del sistema. Este proceso se realiza con 
anterioridad al despliegue de los tags y lectores. 


+ El PKG genera su par de claves pública Hp; y privada 
Kpr 

+. La clave pública Kp, se alamcena en todos los tags y 
lectores 

+ Cada tag se personaliza con un identificador /Dtag;, 
siguiendo una codificación EPC o similar [10] 

e En cada tag se almcena información Dtagioca COn sig- 
nificado local, es decir, algún dato relacionado con la 
localización geográfica en la que será colocado 

e Los datos Dtagioca, son firmados con la clave privada 
que genera el PKG a partir de la identidad del tag. La 
firma Sig; resultante es almacenada también en el tag 


Identificación de los tags. Esta fase consiste únicamente en 
la lectura del contenido de los tags. Es importante recordar que 
la lectura se realiza con el vehículo en movimiento. Cuando 
el tag es interrogado por el lector, éstos son los datos que 
entrega: 

+ Identificación | Dtag; 

. Datos Dtagiocal 

e Firma Sig; de los datos 


Autenticación de los tags. En esta fase el vehículo puede 
comprobar la autenticidad de los datos leidos, una vez que 
ha terminado la comunicación con el tag. La autenticación se 
realiza mediante la verificación de la firma. 


e El lector utiliza la identidad / Dtag, y la clave K pp como 
clave pública para verficar la firma Sig, emitida por el 
tag sobre los datos Dtagiocal 

+. Es necesario verificar también que el contenido de los 
datos Dtagioca: es coherente con la localización ge- 
ográfica en la que se encuentra el vehículo. Con esto se 
consigue detectar la utilización de tags fraudulentos. 


Finalmente, con objeto de asegurar que el sistema funcione 
correctamente, se propone la utilización de otro chip RFID 
de mayor capacidad y velocidad, el ST XRAG2 [24]. Este 
chip trabaja también en UHF pero dispone de 304 bits que 
se pueden utilizar en diversas configuraciones, diviendolo en 
bancos independientes, uno para el codigo EPC y otro para 
memoria de usuario, o en un solo banco dedicado al codigo 
EPC. La velocidad máxima a la que transmite es de 640 
Kbps. Con estos datos, que mejoran sustancialmente los del 
chip empleado en los experimentos de [16], se puede llegar 
a velocidades mayores, sin tener que renunciar a un nivel de 
seguridad aceptable. 


V. CONCLUSIONES 


Si bien es cierto que la utilización de criptografía basada 
en identidad en entornos de VANETs no es algo nuevo, y 
que ya existían propuestas para aplicarla también a sistemas 
RFID, este escenario en el que se integran RFID y VANETs 
no había sido considerado hasta ahora desde un punto de vista 
criptográfico. 

En este trabajo se analizan los requisitos de seguridad de 
estos nuevos escenarios y se propone la utilización de un 
esquema particular basado en identidad que permitiría una 
implementación razonable a partir de datos experimentales. 
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En definitiva, con este trabajo se pretende mostrar una nueva 
situacin en la que la criptografa basada en identidad podra 
ser la solucin una vez resueltos algunos aspectos de imple- 
mentacin. 

En cualquier caso, es necesario avanzar en la imple- 
mentación de estos nuevos escenarios y obtener nuevos datos 
experimentales que permitan una mejor aproximación. 

Por otra parte, la utilización de tags comerciales reduce 
considerablemente las prestaciones del sistema puesto que 
determinados mecanismos que incorporan desde fábrica no 
son necesarios. Por ejemplo, el modo en que los vehículos van 
a leer los tags no requiere un procedimiento anticolisión. En 
consecuencia, los tiempos de espera aleatorios que se producen 
al comienzo de las transmisiones se podrían acortar o incluso 
eliminar, aumentando así las velocidades máximas a las que 
podría funcionar el sistema o aumentando la cantidad de bits 
que el tag puede enviar, permitiendo la implementación de 
esquemas más robustos. 
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Resumen—La sociedad de la información cada vez depende 
más de los Sistemas de Gestión y Análisis del Riesgo al que se 
encuentran sometidos sus principales activos de información, y 
poder disponer de estos sistemas ha llegado a ser vital para la 
evolución de las PYMES. Sin embargo, este tipo de compañías 
requiere que estos sistemas estén adaptados a sus especiales 
características. En este artículo se presenta el método propuesto 
para realizar un análisis de riesgos simplificado, que sea válido 
para las PYMES, y enmarcado dentro de la metodología de 
gestión de la seguridad en las pequeñas y medianas empresas 
(MSM2-PYME). Este modelo está siendo aplicado directamente 
a casos reales, consiguiendo así una constante mejora en su 
aplicación. 

Palabras Clave—PYMES; Análisis de riesgos, Activos; SGSI 


I. INTRODUCCIÓN 


Estudios realizados [1] han demostrado que para que las 
empresas puedan utilizar las tecnologías de la información 
y las comunicaciones con garantías es necesario disponer de 
guías, métricas y herramientas que les permitan conocer en 
cada momento su nivel de seguridad y las vulnerabilidades 
que aún no han sido cubiertas. El problema de conocer los 
riesgos a los que están sometidos sus principales activos se 
acentúa especialmente en el caso de las pequeñas y medianas 
empresas, que cuentan con la limitación adicional de no tener 
recursos humanos y económicos suficientes para realizar una 
adecuada gestión de sus activos [2]. Pero con la llegada de 
Internet, para las empresas es cada vez más critico implantar 
controles de seguridad que les permitan conocer y controlar 
los riesgos a los que pueden estar sometidas [3]. 

Algunos autores [4, 5] sugieren la realización de un análisis 
de riesgos como parte fundamental de la gestión de la se- 
guridad en las PYMES, ya que los propietarios de estos 
activos deben tener en cuenta que el valor y la sanción de 
los datos robados o filtrados en una pequeña organización 
es el mismo que para una grande, y por tanto debe tener 
controlado el valor de los activos y los riesgos a los que 
están sometidos. Otros autores [6] proponen la necesidad 
de desarrollar un nuevo modelo de análisis de riesgos (AR) 
pero orientándolo directamente a las PYMES, dado que las 
características de éstas son diferentes que las de las grandes 
compañías, considerando que el uso de técnicas de análisis y 
gestión de riesgos, así como el papel de terceros, es necesario 
para poder garantizar la seguridad del sistema de información 
de las PYMES. 
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Estudios centrados en la evaluación de riesgos [7-9] real- 
izados sobre organizaciones en Europa y los EE.UU, revelan 
que las PYMES se caracterizan por la falta de la dedicación 
necesaria a la seguridad de las tecnologías de la información, 
debido principalmente a la asignación de responsabilidades 
a personal sin la debida formación. Asimismo, la mayoría 
de las organizaciones carecen de políticas de seguridad y 
sistemas de evaluación del riesgo, llegando al caso en que 
el 73% de los encuestados de PYMES del Reino Unido dijo 
realizar en su casa la evaluación de riesgos. Menos del 10% 
de los encuestados afirmó usar una herramienta de análisis de 
riesgos, y ninguno utilizó una guía de referencia como podía 
ser la ISO/IEC17799 [10]. Esto plantea dudas sobre la manera 
exhaustiva o eficaz en que pueden haberse realizado dichos 
análisis. 

Como tal, una de las cuestiones derivadas de las con- 
clusiones es la necesidad de obtener nuevas metodologías 
y modelos de análisis y gestión del riesgo que se adapten 
a las características especiales de las PYMES [11], con el 
objetivo de eliminar (o al menos reducir) los inconvenientes 
y ayudar a estas compañías a evaluar los riesgos a los que 
sus activos están expuestos y a establecer los controles de 
seguridad adecuados. 

Por lo tanto, y considerando que las PYMES representan 
una gran mayoría de empresas tanto a nivel nacional como 
internacional y son muy importantes para el tejido empresarial 
de cualquier país, [12] creemos que avanzar en la investigación 
para mejorar los procesos de análisis y gestión del riesgo para 
este tipo de empresas puede generar importantes aportaciones. 
Esto puede contribuir a mejorar no sólo la seguridad de las 
PYMES, sino también su nivel de competitividad. Por este 
motivo, a los largo de los últimos años hemos trabajado 
en elaborar un proceso simplificado que permita analizar y 
gestionar el riesgo de seguridad en las PYMES [13, 14] , 
y además hemos construido una herramienta que automatiza 
completamente este proceso [15] , y lo hemos aplicado en 
casos reales [16], lo que nos ha permitido validar tanto la 
metodología como la herramienta. 

El artículo continúa en la Sección II, describiendo breve- 
mente las metodologías y modelos existentes para el análisis 
y la gestión del riesgo de la seguridad y su tendencia actual. 
En la Sección III se introduce brevemente nuestra propuesta 
de metodología para el análisis y la gestión del riesgo de 
la seguridad orientada hacia las PYMES. Finalmente, en la 
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Sección IV concluimos indicando cuál será el trabajo que 
desarrollaremos en el futuro. 


TI. RELATED WORK 


Con el propósito de reducir las carencias mostradas en el 
apartado anterior con respecto a la gestión de la seguridad en la 
PYMES, ha aparecido un gran número de procesos, marcos de 
trabajo y métodos para la gestión del riesgo cuya necesidad de 
uso para proteger de forma eficaz los activos de una compañía 
está siendo cada vez más reconocida y considerada por las 
organizaciones, pero que no terminan de tener éxito en el caso 
de las PYMES. 

A pesar de ello, la gestión de la seguridad no puede limitarse 
al análisis y la gestión del riesgo [17], sino que además de 
identificar y eliminar riesgos el proceso se ha de realizar de 
manera eficiente, obteniendo la compañía grandes ahorros de 
costes como consecuencia directa de una mejor gestión de 
la seguridad [18]. Gracias al análisis de riesgos se podrán 
identificar los activos y conocer el nivel de seguridad que se 
debe aplicar. 

Los estándares de gestión de la seguridad más destacados 
han incorporado procesos para el análisis y la gestión del 
riesgo, pero estos se han mostrado difíciles de aplicar en el 
caso de las PYMES, ya que requieren una gran inversión y 
son difíciles de gestionar [19]. Entre las principales propues- 
tas para el análisis y gestión del riesgo podemos destacar 
MAGERIT [20], OCTAVE [21]] o CRAMM [22]. 

Por otro lado, algunos de los principales estándares de 
gestión de la seguridad han intentando incorporar dentro de 
sus procesos el análisis y la gestión del riesgo: 


e ISO/IEC27005 [23]: Establece las directrices para la 
gestión del riesgo en la seguridad de la información. 
Apoya los conceptos generales especificados en la norma 
1S0/IEC27001 [24] y está diseñada para ayudar a la 
aplicación satisfactoria de la seguridad de la información 
basada en un enfoque de gestión de riesgos. 
ISO/IEC21827/SSECMM [25]: El modelo de capacidad 
y madurez en la ingeniería de seguridad de sistemas 
describe las características esenciales de los procesos que 
deben existir en una organización para asegurar una buena 
seguridad en los sistemas, incluyendo en las fases previas 
un proceso orientado al riesgo, con 4 subprocesos: SSE- 
PA02 (Determinar el impacto), SSE-PA03 (Identificar los 
riesgos de seguridad), SSE-PAO4 (Identificar las ame- 
nazas), SSE-PAOS (Identificar las vulnerabilidades). 
COBTIT: Es una metodología para el adecuado control de 
los proyectos de tecnología, los flujos de información y 
los riesgos que implica la falta de controles adecuados. 
Incluye un proceso orientado a evaluar los riesgos, en el 
dominio PO9. Este proceso se centra principalmente en 
los criterios de confidencialidad, integridad y disponibil- 
idad, y de forma secundaria en criterios de efectividad, 
eficiencia, cumplimiento y confiabilidad. Por último, este 
proceso involucra a diversos perfiles (RRHH, Sistemas de 
Información, Tecnología, Instalaciones y Datos) involu- 
crados en el sistema de información. 


Por otro lado, existe un pequeño conjunto de herramientas 
de análisis de riesgos. Actualmente las más utilizadas son 
PILAR y EAR, basadas en Magerit v2 [20]. Otras herramientas 
utilizadas son la propuesta por ENISA, que incluye un sistema 
de comparativas, OCTAVES y Octave Automated Tool, que 
implementan la metodología de evaluación de riesgos OC- 
TAVE [21], CRAMM y COBRA. 

El principal problema de estos procesos y herramientas es su 
complejidad para aplicarlos en el caso de las PYMES, ya que 
han sido concebidos para grandes empresas [26]. Se justifica 
en repetidas ocasiones [27, 28] que la aplicación de este tipo 
de procesos para las PYMES es difícil y costosa. Además, 
las organizaciones, incluso las grandes, tienden más a adoptar 
grupos de procesos relacionados como un conjunto que a tratar 
los procesos de forma independiente [29]. 

Por lo tanto, y como conclusión de este apartado, se puede 
decir que es pertinente y oportuno abordar el problema de 
desarrollar un nuevo proceso para el análisis y gestión del 
riesgo de la seguridad para los sistemas de información en 
las PYMES, así como una herramienta que soporte este 
proceso, tomando como base la problemática a que este 
tipo de compañías se enfrenta y que ha llevado a continuos 
fracasos [30] en los intentos de implantación de un SGSI en 
este tipo de empresas. 


TI. GESTIÓN DEL RIESGO DE LOS ACTIVOS EN LAS 
PYMES 


Para solucionar los problemas detectados en el análisis y 
gestión del riesgo a la hora de aplicarlo en las PYMES, se ha 
desarrollado un nuevo proceso orientado a gestionar el riesgo 
en este tipo de compañías denominado ARM-PYME, con dos 
premisas básicas: 1) orientado a las PYMES; y 11) enfocado a 
reducir los costes de generación y mantenimiento del proceso 
de análisis y gestión del riesgo. 

Este proceso se ha obtenido mediante la aplicación del 
método de investigación en acción [31] y se ha enmarcado 
dentro de la metodología (MSM2-PYME) [32] que acomete 
todos los aspectos relacionados con la gestión de la seguridad. 

Dentro de la metodología, el proceso que se encarga del 
análisis y la gestión del riesgo esta formado por dos activi- 
dades: 

. Actividad I: Se establece una estructura de relaciones 
entre los diferentes elementos involucrados en el análisis 
del riesgo y los controles necesarios para gestionar la 
seguridad. Estas relaciones se establecen mediante el 
conocimiento adquirido en las diferentes implantaciones, 
que es almacenado en una estructura denominada es- 
quema para ser reutilizado con posterioridad, reduciendo 
los costes de generación de este proceso. 

Actividad Il: Mediante la selección del esquema más 
adecuado y la identificación de un pequeño conjunto 
de los principales activos se obtiene un detallado mapa 
de la situación actual (análisis del riesgo) y un plan de 
recomendaciones de cómo mejorarlo (gestión del riesgo). 


Para entender correctamente el proceso es importante cono- 
cer el concepto de Esquema. Se trata de una estructura formada 
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por los principales elementos de un SGSI y las relaciones 
que se pueden establecer entre ellos, mediante el Know- 
How adquirido en diferentes implantaciones. Esta estructura 
puede ser reutilizada por un conjunto de compañías con 
características comunes (mismo sector y tamaño) a partir del 
conocimiento adquirido con la implantación de la metodología 
MSM2PYME y posteriores refinamientos. 

Este apartado se divide en dos subapartados, que se corre- 
sponden con las dos actividades del proceso. 


A. ARM-PYME Actividad 1: Análisis de riesgos como parte 
de un Esquema. 


El principal objetivo de esta actividad es seleccionar los 
elementos necesarios para poder realizar, en actividades pos- 
teriores de la metodología, un análisis de riesgos básico y de 
bajo coste (que se adapte a los requerimientos de las PYMES) 
sobre los activos que componen el sistema de información de 
la compañía. 

Esta actividad está basada en las conclusiones obtenidas 
durante la aplicación del método de investigación-acción [31] 
a diferentes casos de estudio, las cuales han permitido determi- 
nar que los elementos que participan en un análisis de riesgos 
y sus relaciones tienen un alto grado de coincidencia cuando se 
aplican en PYMES que tienen características parecidas (mismo 
sector y mismo tamaño), por lo que se pueden establecer 
dichas relaciones a priori eliminando el coste de tener que 
analizarlas una por una mediante una labor de consultoría en 
cada caso. Aún cuando existan diferencias entre unas y otras, 
éstas son irrelevantes con respecto a la configuración final del 
SGSI obtenido para el caso de las PYMES, dado que este tipo 
de empresas priorizan el coste a obtener un resultado con un 
alto grado de precisión. 

En la Figura 1 se puede ver el esquema básico de entradas, 
tareas y salidas que componen esta actividad: 


Entradas Tarcas Salidas 
GEGS-Al 
Conocimiento SES> 


de expertos 


=== 
Repositorio de 
Esquemas 


en seguridad 


| Tis | 
| Tio | 
¡ma | 
| ms | 


Fig. 1. Esquema simplificado a nivel de tarea de la actividad Al. 


e Entradas: Como entrada se recibirá el conocimiento 
del grupo de expertos del dominio de seguridad (EGD) 
obtenido durante el proceso de implantación de SGSIs, 
así como un conjunto de controles para la gestión de se- 
guridad que se encuentran almacenados en el repositorio 
de esquemas y un conjunto de elementos necesarios para 
elaboración del análisis de riesgos. 


e Tareas: El subproceso estará formado por ocho tareas que 
se analizarán en detalle posteriormente. 

e Salidas: La salida producida por este subproceso con- 
sistirá en un subconjunto de los elementos de entrada 
y las relaciones establecidas entre ellos, los cuáles se 
almacenarán en el repositorio de esquemas y que se 
corresponden con la tercera parte de los elementos de 
los que se compondrá el esquema que se quiere generar. 


A continuación, se analizarán las diferentes tareas del pro- 
ceso que involucran y manipulan los elementos del análisis de 
riesgos. 


. Tarea Tl.1 Selección de tipos de activos: Se ocupa de 
seleccionar el conjunto de tipos de activos que formarán 
parte del esquema que se está construyendo. Los tipos de 
activos se utilizarán posteriormente para diversas tareas: 
1) agrupar los activos del sistema de información; 11) se 
relacionarán con otros elementos del análisis de riesgos 
para facilitar la automatización del mismo. 

e Tarea T1.2 Selección de amenazas: Se ocupa de se- 
leccionar el conjunto de amenazas que formarán parte 
del esquema que se está construyendo. Una amenaza 
se define como un evento que puede desencadenar un 
incidente en la organización, produciendo daños mate- 
riales o pérdidas inmateriales en sus activos [20]. Estas 
amenazas se relacionarán en tareas posteriores con otros 
elementos del análisis de riesgos, con el objetivo de poder 
automatizar y reducir los costes a la hora de evaluar el 
riesgo al que están sometidos los activos de un sistema 
de información. 

e Tarea TI.3 Selección de vulnerabilidades: Se ocupa 
de seleccionar el conjunto de vulnerabilidades que for- 
marán parte del esquema que se está construyendo. Una 
vulnerabilidad se define como una debilidad o falta de 
control que permitiría o facilitaría que una amenaza 
actuase contra un activo del sistema que presenta la citada 
debilidad [20]. Estas vulnerabilidades se relacionarán en 
tareas posteriores con otros elementos del análisis de 
riesgos, con el objetivo de poder automatizar y reducir 
los costes a la hora de evaluar el riesgo al que están 
sometidos los activos de un sistema de información. 

e Tarea T1.4 Selección de criterios de riesgo: Se ocupa 
de seleccionar el conjunto de criterios de riesgo que 
formarán parte del esquema que se está construyendo. 
Los criterios de riesgo se definen como aquellos criterios 
que permiten estimar el grado de exposición a que una 
amenaza se materialice sobre uno o más activos causando 
daños o perjuicios a la organización. Estos criterios de 
riesgo se relacionarán en tareas posteriores con otros 
elementos del análisis de riesgos, con el objetivo de poder 
automatizar y reducir los costes a la hora de evaluar el 
riesgo. 

. Tarea T1.5 Establecer relaciones entre tipos de activos 
y vulnerabilidades: Se ocupa de establecer las relaciones 
existentes entre los elementos que componen el conjunto 
de tipos de activos y los elementos que componen el con- 
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junto de vulnerabilidades para un esquema determinado. 

. Tarea TI.6 Establecer relaciones entre amenazas y 
vulnerabilidades: Se ocupa de establecer las relaciones 
existentes entre los elementos que componen el conjunto 
de amenazas y los elementos que componen el conjunto 
de vulnerabilidades para un esquema determinado. 

e Tarea Tl1.7 Establecer relaciones entre amenazas y 
controles: Se ocupa de establecer las relaciones exis- 
tentes entre los elementos que componen el conjunto de 
amenazas y los elementos que componen el conjunto de 
controles para un esquema determinado. 

e Tarea T1.8 Establecer relaciones entre tipos de activos, 
vulnerabilidades y criterios de riesgo: Se ocupa de es- 
tablecer las relaciones existentes entre los elementos que 
componen el conjunto de tipos de activos, los elementos 
que componen el conjunto de vulnerabilidades y los 
elementos que componen el conjunto de criterios de 
riesgo para un esquema determinado. 


Las asociaciones de las tareas T1.5-8 se establecen por el 
grupo de expertos del dominio (EGD) en base al conocimiento 
adquirido en diferentes implantaciones del SGSI. 


B. AGR-PYME Actividad 2: Aplicación del análisis de ries- 
80S. 


El principal objetivo de esta actividad es establecer una 
evaluación de los riesgos a los que se encuentran sometidos los 
principales activos del sistema de información de la compañía 
sobre la que se quiere implantar el SGSL, así como proponer 
un plan al responsable de seguridad (Cu/RS) para gestionar 
los riesgos de la forma más eficiente posible. 

En la Figura 2 se puede ver el esquema básico de entradas, 
tareas y salidas que componen esta actividad: 

Salidas 


Entradas Tareas 


GSGS - A2 
QU 


f InfAct, InfMR, InfPM 


Inf. SGSI 


A 
== 


===, 
Repositorio de 
SGSIs 


Fig. 2. 


Esquema simplificado a nivel de tarea de la actividad A2. 


e Entradas: Como entrada se recibirá: 1) un esquema 
de los existentes en el repositorio de esquemas, que 
será seleccionado por el consultor de seguridad (SCo) 
en base a las características de la compañía (sector y 
tamaño de la misma), del que se obtendrán los elementos 
necesarios para la realización del análisis de riesgos; 
11) el interlocutor (Int) válido para la compañía, que se 
encargará de definir los activos; 111) un conjunto de activos 
del sistema de información, lo más generalistas posible 
(grano grueso). 


e Tareas: El subproceso estará formado por dos tareas que 
se analizarán en detalle posteriormente. 

. Salidas: La salida producida por este subproceso consi- 
stirá en una serie de entregables (informe de activos del 
sistema de información, matriz de riesgos a los que están 
sometidos los activos del sistema de información y plan 
de mejora recomendado por la metodología para afrontar 
las mejoras en la gestión de la seguridad del SGSI) para 
que el consultor de seguridad (SCo) pueda analizarlos. 

El desarrollo de esta actividad está basado en la propuesta de 
Stephenson [33], que se centra en la sinergia entre la prueba 
técnica y el análisis de riesgos tomando como referencia la 
ISO/TEC 27002 [34] y en la metodología de análisis de riesgos 
Magerit v2 [20]. Estas metodologías suelen producir rechazo 
en el caso de las PYMES debido a que las perciben como 
demasiado complejas, a que requieren un enorme compromiso 
por parte de los miembros de la compañía y a que los costes 
asociados a los mismos no son aceptados por estas compañías. 
Por ello, la metodología MSM2PYME simplifica el proceso 
de evaluación del riesgo para adecuarlo a las PYMES. 

Las principales bases sobre las que se define esta ac- 
tividad son: flexibilidad, simplicidad y eficiencia en costes 
(humanos y temporales). Se trata, pues, de una actividad que 
pretende identificar con el menor coste posible los activos 
de la compañía y los riesgos asociados, usando para ello 
los resultados generados en las actividades anteriores y unos 
sencillos algoritmos. 

La parte de análisis de riesgos de la metodología desar- 
rollada toma algunos aspectos de Magerit v2 [20] y algunos 
aspectos de los análisis de riesgos clásicos, pero en todo 
momento tiende a la simplificación. 

Para que esta actividad funcione de forma coherente se 
deben tener en cuenta las condiciones especiales de las 
PYMES, en las que los usuarios no suelen tener ni el tiempo 
ni los conocimientos adecuados para aplicar de forma eficiente 
metodologías de análisis de riesgos, ni para determinar de 
forma adecuada los activos de los sistemas de información. 

Al igual que en la actividad anterior, cuando se trata 
de PYMES no se busca la opción óptima sino una opción 
razonablemente buena que permita grandes reducciones de 
tiempos a la hora de obtener el resultado. 

Las tareas de esta actividad se apoyan principalmente en 
los datos que componen el esquema seleccionado, generado 
durante la actividad Al, y en una lista de controles de 
seguridad. 

A continuación mostramos en detalle las tareas que compo- 
nen la actividad: 

. Tarea T2.1 Identificación de activos: El objetivo de esta 
tarea es obtener un conjunto de los activos que componen 
el sistema de información de la empresa. Los activos 
definidos son el objetivo principal hacia el que se enfoca 
el SGSI, ya que son los elementos que se pretenden 
proteger. 

Una de las diferencias principales que presenta el 
método para la evaluación del riesgo presentado en la 
metodología es que se busca que los activos sean lo 
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más generales posible (grano grueso), frente a [20], que 
intenta identificarlos de forma clara y precisa (grano fino). 
En las PYMES se debe intentar definir un conjunto 
muy pequeño y básico de activos, ya que su sistema 
de información no permite la protección discriminada de 
activos de baja atomicidad ni puede soportar el coste 
de gestión de los mismos. Por lo tanto, en esta tarea 
se buscarán activos generales que se puedan valorar de 
forma sencilla tanto desde el punto de vista cuantitativo 
como cualitativo. 

En esta tarea el consultor de seguridad (SCo) deberá 
ayudar el interlocutor (Int) a identificar el conjunto de 
activos de valor que componen el S.I. de la compañía. 

e Tarea T2.2 Generación de matriz de riesgos y plan 
de mejora: El objetivo de esta tarea es realizar una 
evaluación de los riesgos a los que están sometidos los 
activos de la empresa definidos en la tarea T2.1. 

Esta tarea requiere de los datos generados durante la 
actividad Al y de los activos identificados en la tarea T2.1 
para generar una matriz riesgos que muestre de forma 
detallada los riesgos a los que está sometido cada activo 
y un plan de mejora que determine cómo acometer estos 
riesgos. 

El plan de mejora se soporta sobre los resultados 
obtenidos de la matriz de riesgos. La matriz de riesgos 
y el plan de mejora son utilizados por el consultor 
de seguridad (SCo) para determinar y analizar medidas 
adicionales y urgentes que deban tomarse en la compañía 
para mitigar riesgos elevados sobre los activos de infor- 
mación de la misma. 

El primer objetivo de esta tarea es generar una matriz 
de riesgo que nos permita conocer los riesgos a los 
que está sometido cada activo de la compañía en cada 
nivel de madurez y para cada elemento del análisis de 
riesgos (amenazas, vulnerabilidades y criterios de riesgo). 
El resultado será una tabla con las siguientes columnas: 1) 
Nivel de Madurez; 11) Nombre y descripción del activo; 
111) Coste del activo; iv) Valor estratégico; v) Tipo de 
activo; vi) Amenaza; vii) Vulnerabilidad; viii) Criterios 
de riesgo; 1x) Nivel de la amenaza (LT); x) Nivel de 
probabilidad (P); xi) Nivel de riesgo (RL); x11) Nivel de 
control o cobertura. 


El valor obtenido en el nivel de riesgo (RL) se gestionará 
según la Tabla I y se moverá en un rango comprendido entre 
1 (menor riesgo) y 7 (mayor riesgo). Se ha determinado que 
el nivel del riesgo residual (RRL), es decir, el que tiene 
actualmente la compañía, nunca debe ser superior al nivel de 
riesgo aceptable (ARL), que es al que debe tender la compañía. 
Para el proceso AGR-PYME se ha considerado que el ARL 
debe ser menor o igual a 3. Si el RL fuera superior al ARL, 
se procede a la selección de salvaguardas para la reducción 
del riesgo, realizando el proceso de forma recursiva hasta que 
el nivel de riesgo de la compañía sea el adecuado. 


Para poder obtener de una forma sencilla el riesgo al que 
está sometido cada activo y el nivel de cobertura de cada 


Tabla I 
CUADRO PARA DETERMINAR EL NIVEL DE RIESGO. 


ARL=<3 


Valor 


activo 


control se utilizará el algoritmo de Matriz de Riesgos (RMa). 

Una vez que se ha obtenido la matriz de riesgos, se utilizará 
- junto con la información generada en las tareas anteriores 
- para obtener el plan de mejora, mediante la aplicación del 
algoritmo del Plan de Mejora (aPM). Este algoritmo funciona 
de forma recursiva, determinando el activo de mayor riesgo en 
el menor nivel de madurez, y aplicando el control que permita 
mejorarlo con el menor coste, para posteriormente recalcular 
todo el proceso y seleccionar el siguiente mejor, hasta llegar 
al nivel de gestión de seguridad óptimo. 


TV. CONCLUSIONES 


En este artículo se ha presentado la propuesta de un proceso 
para realizar el análisis y gestión del riesgo en las PYMES 
denominado ARM-PYME, que permite soportar los resultados 
generados durante la investigación y que cumple con los 
objetivos perseguidos. 

Se ha definido cómo se puede utilizar este proceso y las 
mejoras que ofrece con respecto a otros modelos que afrontan 
el problema de una forma más precisa y detallada, pero 
también más costosa, lo que no los hace válidos para el caso 
de las PYMES. 

Las características ofrecidas por el proceso y su orientación 
a las PYMES han sido muy bien recibidas, y su aplicación está 
resultando muy positiva ya que permite a este tipo de empresas 
realizar una adecuada gestión del riesgo al que están sometidos 
los activos de su sistema de información. Además, con este 
proceso se obtienen resultados a corto plazo y se reducen los 
costes que supone el uso de otros procesos, consiguiendo un 
mayor grado de satisfacción de la empresa. 

El proceso ARM-PYME cumple con los objetivos prop- 
uestos, así como con los principios que según la Organización 
para la Cooperación y el Desarrollo Económico (OECD) [35] 
debe seguir todo proceso de evaluación del riesgo, según la 
cuál el sistema debe tener la capacidad de autoevaluar su riesgo 
de forma continuada en el tiempo, proponiendo medidas. 

Finalmente, se considera que el trabajo realizado debe 
ser ampliado con nuevas especificaciones, nuevos esquemas, 
mejorando los algoritmos de análisis y gestión del riesgo de 
forma que puedan ofrecer planes más detallados y profun- 
dizando en el proceso con nuevos casos de estudio. 

La mayor parte de las futuras mejoras del proceso se están 
orientando a mejorar la precisión del mismo, pero siempre 
respetando el principio de coste de recursos, es decir, se busca 
mejorar el proceso sin incurrir en costes de generación y 
mantenimiento del análisis de riesgos. 
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Abstract— The goal of the feature selection process in network 
intrusion detection is to determine the minimal set of network 
traffic features that ensures accurate intrusion detection in the 
most efficient way. Obtaining automatically a good set of such 
features is a great research challenge. The problem is in a huge 
cardinality of the power set of the full feature set. In this paper, 
we transform the correlation feature selection (CFS) problem into 
a polynomial mixed 0-1 fractional programming problem and by 
solving that problem we get the globally optimal solution of the 
CES problem. We describe a sequence of transformations of the 
original optimization problem into a program with the number 
of constraints that is linear in the number of full set features. 
Our feature selection algorithm was compared experimentally 
with the best-first-CFS and the genetic-algorithm-CFS methods 
regarding the feature selection capabilities. The classification 
accuracy obtained after the feature selection by means of the 
C4.5 and the BayesNet machines over the KDD CUP99 IDS 
benchmarking data set was also tested. Experiments show that 
our feature selection method outperforms the best first and 
the genetic algorithm search strategies by removing much more 
redundant features and still keeping the classification accuracies 
or even getting better performances. 


TI. INTRODUCTION 


Network-based intrusion detection systems (IDS) gather 
and analyze information from networks in order to identify 
suspicious activities and generate alerts for an operator. Such 
a task is often analyzed as a pattern classification problem 
- an IDS has to tell normal from abnormal activities in 
networks. The theoretical models of IDS (see for example 
[4], [6]) usually include the representation algorithm (for 
representing incoming data in the space of selected features) 
and the classification algorithm (for mapping the feature 
vector representation of the incoming data to elements of a 
certain set of values, e.g. normal or abnormal etc.) Some IDS 
models, like those presented in [6], also include the feature 
selection algorithm, which determines the features to be used 
by the representation algorithm. Even if the feature selection 
algorithm is not included in the model directly, it is always 
assumed that such an algorithm is run before the very intrusion 
detection process. 

The goal of the feature selection algorithm is to determine 
the most relevant features of incoming traffic, whose monitor- 
ing ensures reliable detection of abnormal behaviour. Since the 
effectiveness of the classification algorithm heavily depends on 
the number of features, it is of interest to minimize the cardi- 
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nality of the set of selected features without dropping potential 
indicators of abnormal behaviour. Obviously, determining a 
good set of features is not an easy task. The most of the work 
in practice is still done manually and the feature selection 
process depends too much on expert knowledge. Automatic 
feature selection for intrusion detection remains therefore a 
great research challenge. 

In this paper, we approach the problem of feature selection 
for intrusion detection from the operational research point of 
view. We propose an automatic feature selection procedure 
based on so-called filter method [7], [10] used in machine 
learning. The filter method directly considers statistical char- 
acteristics of the data set, such as correlation between a feature 
and a class or inter-correlation between features, without 
involving any learning algorithm. We focus on one of the most 
important filter methods, the Correlation Feature Selection 
(CFS) measure proposed by M. Hall [8]. The CFS measure 
is combined with some search strategies, such as brute force, 
best first search or genetic algorithm, in order to find the most 
relevant subset of features. The brute force method can only 
be applied when the number of features is small. In other 
cases, a more intelligent optimization algorithm in the feature 
selection process is needed. With the best first search or the 
genetic algorithm, we can deal with high dimensional data 
sets, but these methods usually give locally optimal solutions. 
To get the globally optimal feature set, we formulate the 
problem of feature selection by representing the CFS measure 
as a polynomial mixed O - 1 fractional programming (PO1FP) 
problem. We improve the Changs method [1], [2] in order 
to equivalently reduce this POIFP to a mixed O - 1 linear 
programming (MO1LP) problem [1]. Finally, we propose to 
use the branch-and-bound algorithm to solve this MOILP, 
whose optimal solution is also the globally optimal subset of 
relevant features by means of the CFS measure. 

Any feature selection algorithm selects relevant traffic fea- 
tures based on labelled data. We used the KDD CUP99 [9] data 
set for this purpose. The full feature set assigned to this data 
set consists of 41 features. For evaluating the performance of 
our feature selection approach, two available feature selection 
methods based on the CFS measure were implemented [3]. 
The first one was the best-first-CFES method using the best- 
first search strategy to find the locally optimal subset of 
features by means of the CFS measure. The second one 
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used the genetic algorithm and therefore we call that feature 
selection approach a genetic-algorithm-CFS method. To test 
the overall effectiveness of an IDS employing our feature 
selection algorithm, 10% of the overall (5 million records) 
KDD CUP99 IDS benchmarking labelled data set were used to 
train and to test C4.5 [11] and BayesNet [5] machine learning 
algorithms with 5-fold cross-validation. Experiments show that 
an IDS applying our feature selection algorithm outperforms 
the IDS implementing the best first and genetic algorithm 
search strategies in the feature selection process. Our method 
removes much more redundant features and the classification 
accuracies with the reduced feature set are kept at the same 
level or they become even better. 

The paper is organized as follows. Section II describes the 
CFS measure in more detail. We show how to represent the 
problem of feature selection by means of the CFS measure as a 
polynomial 0-1 fractional programming (P01FP) problem. The 
background regarding PO1FP, MO1LP problems and Chang's 
method is also introduced in this section. Section III describes 
our new approach. We present some experimental results in 
Section IV. The last section summarizes our findings. 


II. BACKGROUND 
A. Correlation feature selection measure 


The Correlation Feature Selection (CFS) measure evaluates 
subsets of features on the basis of two concepts: the feature- 
classification (r¿f,) correlation and the feature-feature (r y, f,) 
correlation. The following equation used in [8] gives the merit 
of a feature subset S consisting of k features: 


KTef 
VE + k(k-— Dr 


Here, T¿f is the average feature-classification correlation, 
and Tff is the average feature-feature correlation, as given 
below: 


Merits(k) = (1) 


Tef, FTefa H---ETefa 
dd 


Tf E ffs E a 
Yi = ———— SA 


k(k—1) 


Therefore, we can rewrite (1) as follows: 


Merits(k) = IE O / EN 0) 


k+2T 5 fa PT ffs ho ET ff) 
Suppose there are n full set features. We need to find the 
subset S of k features, which has the maximum value of 
Merits(k) over all 2” possible feature subsets: 


max [Merits(k),1<k<mn). €) 


We now propose a new method to find the globally optimal 
subset of features. To this end, we formulate the CFS feature 
selection task as so-called fractional programming problem. 
We use binary values of the variable x, in order to indicate 


the appearance (x, = 1) or the absence (1; = 0) of the feature 
f;¡ in the optimal subset of features. Therefore, the problem 
of selecting features by means of the CFS measure can be 
described as a fractional programming problem as follows: 


Fa) = 2er 


AE Dit 27 p, 1, ViLj 


= Oi1 dia)? 
ia Ti + 201042 
In the following subsection, we consider the problem stated 
above as a polynomial mixed 0 — 1 fractional programming 
(PO01F'P) problem and show how to solve it. 


(5) 


B. Polynomial Mixed 0 — 1 Fractional Programming 


A general polynomial mixed O — 1 fractional programming 
(P01F"P) problem [2] is represented as follows: 


E + 1 4 Trey Er 
min ERA ÉÁ (6) 
2, di + ja dis Mpey Tn 


subject to the following constraints: 
b; + jaa bi Ilse Li >00= 1... mM; 
Cp + Djz1 Cpj Tpe y Er <0p=1,...,m, 
Tk € (0, 11% € J, 


Q;, Di, Cp, Aj» Diz, Cp ER. 
By replacing the denominators in (6) by positive variables 


yi(i= 1,...,m), the POLF'P is transformed to the following 
equivalent polynomial mixed 0 — 1 programming problem: 


min y, (ais - y Qi; II 2) (7) 
j=1 


j=1 keJ 


subject to the following constraints: 
diYi + RO dis llkey TrYi = 1; Ys > 0,4 =1,..., m, 
Cp + ica Coi Ulye Tr < 0,p= 1,..., m, 
2h €[0,1),k€ J, 


Q;, di, Cp) Qi, bis, Coj € R. 

(8) 
In order to solve this problem, Chang [2] proposed a 
linearization technique to transfer the terms TI keJ Uk Yi into a 
set of mixed 0— 1 linear inequalities. Based on this technique, 
the POLFP becomes then a mixed 0 — 1 linear programming 
problem (M01L£LP), which can be solved by means of the 

branch-and-bound method to obtain the global solution. 
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Proposition 1: A polynomial mixed 0 — 1 term [[,.¿ ; 14Yi 
from (7) can be represented by the following program [1]: 
min z; 
subject to the following constraints: 


a 2 MODs (UD +4, 
(9) 
Zi 2 0, 


where M is a large positive value. 

Proposition 2: A polynomial mixed 0 — 1 term [[,.¿ ; 1xYi 
from (8) can be represented by a continuous variable v,, 
subject to the following linear inequalities [1]: 


Y; > MX ges Th — 11) + y, 


Vi < M(J| AS ES Lp) T Yi» (10) 


0< vw < Mz;, 


where M is a large positive value. 

We now formulate the optimization problem of the CES 
measure (5) as a polynomial mixed O — 1 fractional program- 
ming (P01F'P) problem. 

Proposition 3: The optimization problem of the CFS mea- 
sure (5) can be considered as a polynomial mixed O — 1 
fractional programming (PO1F'P) problem. 

Proof. We change the sign of F(x) in (5) to make a 
minimum problem and decompose the numerator of (5) as 
follows: 


1D 


n n 

> j 2 , 2 2 > 

( 052) = Q Tá + 2a0j0 ¡LL 
i=1 i=1 


Aj 


Therefore, (5) can be written as (6). M 

Remark: By applying the Chang's method, we can trans- 
form this PO1F'P problem to the M/01LP problem. The num- 
ber of variables and constraints will depend on the square of n, 
where n is the number of features. The reason for this is that 
the number of terms [ [,, y 2; Y, Which are replaced by the new 
variables in forms Dis 2a,058,8,Y) or (Dis; 2b,¿U425Y), 
is n(n — 1)/2. The branch-and-bound algorithm can then be 
used to solve this 1/01LP problem. But the efficiency of 
the method depends strongly on the number of variables and 
constraints. The larger the number of variables and constraints 
an MO1LP has, the more complicated the branch-and-bound 
algorithm is. 

In the following section, we present an improvement of the 
Chang's method to get an MO1LP with a linear number of 
variables and constraints in the number of full set variables. 
We also describe a new search strategy to obtain the relevant 
subsets of features by means of the CFS measure. 


TIT. OPTIMIZATION OF THE CFS MEASURE 


By introducing an additional positive variable, denoted by 
y, we now consider the following problem equivalent to (5): 


minf-F(x)) =-— Y 0j0jT;)15Y (12) 
j=1 i=1 
subject to the following constraints: 
y >0, 
x= (21,12,..., 27) € L0,1P", (13) 


Dia TiY + Ei id b,2,)xjy =1. 


Here, all the terms ajajw,2j in the numerator and 
the terms b,x,¿wj in the denominator of (5) have been 
grouped into the sum (9>;_,(0;=1 040424)1,y) and the sum 
(j1 O i1.1%5 P317:)154), respectively. Each sum contains 
n terms, which will be equivalently replaced by new variables 
with constraints following the two propositions given below: 

Proposition 4: A  polynomial mixed 0 — 1 term 
O77_, aa,2;)2,y from (12) can be represented by the fol- 
lowing program: 

min 2; 
subject to the following constraints: 


42 Mía 1) + (ias 0j24)y, 
(14) 


where M is a large positive value. 

Proof. 

(a) If x, =0, then 2¿ > M(0— 1D) +07; ajaja¡)Jy <0 
will force min 2; to be zero, because 2; > O and 1 is a large 
positive value. 

(b) If xy =1, then 2, > M(1- 1)+ O), ajajz;)y > 0 
will force min z; to be ();_, ajazx;)y, because 2, > 0. 

Therefore, the program on 2; presented above reduces to: 


0, if Lj= 0, 


(1 14042)Y, 


which is the same as (>>;_, aja¿2,Ju;y = min z;. M 

Proposition 5: A  polynomial mixed 0 — 1 term 
Qiiitj b,¡x,)x;y from (13) can be represented by a con- 
tinuous variable v;, subject to the following linear inequality 
constraints: 


min 2; = 
if 25 = ll, 


y 2 M(x, —1)+ Qiritj bjti)y, 


Qiritj bji2;)Y, 


y <M(1-2)+ (15) 


0 AS Uv; $ M5, 


where M is a large positive value. 
Proof. 
(a) If x, =0, then (15) becomes 
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vy > M(O— 1) + (ica 4 Piti dy, 
uy S M0) + Oia 2 di 20dY, 
0 $ Uv; < O. 


vj is forced to be zero, because M is a large positive value. 
(b) If x, = 1, then (15) becomes 


vu > M(1-1)+ Qiritj djiti)Y, 
v £€ M(1-1)+ idas bjiLi)Y, 
0 < U; < M. 


vz is forced to be (Dj, ¿2;D3505)y, because M is a large 
positive value. 
Therefore, the constraints on v; reduce to: 


0, if Lj = 0, 
UY = 
Qi=titj bji2;)Y, 


which is the same as (D7¿_1 ¿2 d31:)2y = 03. M 

We substitute each term x,y in (13) by new variables 
t, satisfying constraints from Proposition 2. Then the total 
number of variables for the MO1LP will be 4n + 1, as they 
are 2;, y, t;, 2; and v; (i,j =1,...,n). Therefore, the number 
of constraints on these variables will also be a linear function 
of n. As we mentioned above, with Chang's method [2] the 
number of variables and constraints depends on the square 
of n. Thus our new method improves Chang's method by 
reducing the complexity of the branch and bound algorithm. 

We now present a new search strategy for obtaining subsets 
of relevant features by means of the CFS measure. 


if 25 = 1, 


» Step 1: Calculate all feature-feature (r y, y,) and feature- 
classification (7, f,) correlations from the training data set. 

. Step 2: Construct the optimization problem (4) from the 
correlations calculated above. In this step, we can use 
expert knowledge by assigning the value 1 to the variable 
zx; if the feature f, is relevant and the value O otherwise. 

. Step 3: Transform the optimization problem of CFS to 
a mixed 0 — 1 linear programming (MO01LP) problem, 
which is to be solved by the branch-and-bound algorithm. 
A non-zero integer value of x, from the optimal solution 
indicates the relevance of the feature f; regarding the CFS 
measure. 


IV. EXPERIMENTAL WORK 
A. Experimental setting 


For evaluating the performance of our new CFS-based 
approach, two available feature selection methods based on 
the CFS measure [3] were implemented. The first one is the 
best-first-CFS method, which uses the best first search strategy 
to find the locally optimal subset. The second one uses the 
genetic algorithm for search. Note that the best first search 
and the genetic algorithm do not guarantee to find the globally 


TABLE I 
THE PARTITION OF KDD CUP”99 DATA SET USED IN THE EXPERIMENT 


Classes Number-of-instances Percentage 
KDD99-normal 97.278 18.30% 
KDD99-DoS 391.458 73.14% 
KDD99-Probe 41.113 7.74% 
KDD99-U2R 52 0.01% 
KDD99-R2L 1.126 0.21% 
Total 531.027 100% 


optimal solution. We can overcome this problem with our new 
method. We did not choose the exhaustive search method since 
it is not feasible for feature selection from data sets with a large 
number of features. We applied machine learning algorithms 
for evaluating the classification accuracy on selected features, 
since there is no standard IDS. 

We performed our experiment using 10% of the overall 
(5 million records) KDD CUP”99 IDS benchmarking labelled 
data set [9]. This data set contains normal traffic and four main 
attack classes: (1) Denial of Service (DoS) attacks, (14) Probe 
attacks, (141) User to Root (U2R) attacks and (iv) Remote 
to Local (R2L) attacks. The numbers of instances for the 
four attack classes and the normal class are quite different. 
For example, the ratio of the number of U2R attacks and the 
number of DoS attacks is 1.3 x 107*, Details on the numbers 
of class instances are given in Table /. 

We tested the performance of our newly proposed CES- 
based feature selection method as follows: 


1) Feature selection is performed on the basis of the whole 
data set: (la) Each attack class and the normal class are 
processed individually, so that a five-class problem can 
be formulated for feature extraction and classification 
with a single classifier. (1b) All attack classes are fused 
so that a two-class problem can be formulated, meaning 
the feature selection and classification for normal and 
abnormal traffic is performed. It might be well possible 
that the attack-recognition results are not satisfactory for 
all of the classes, since the numbers of class instances 
are unevenly distributed. In particular, the classes U2R 
and R2L are under-represented. The feature selection 
algorithm and the classifier, which is used for evaluation 
of the detection accuracy on selected features, might 
concentrate only on the most frequent class data and 
neglect the others. As a consequence, we might miss 
relevant characteristics of the less represented classes. 

2) As the attack classes are distributed so differently, we 
prefered to process these attack classes separately. With 
the specific application of IDS we can also formulate 
four different two-class problems. Four classifiers shall 
be derived using specific features for each classifier in 
order to detect (identify) a particular attack. The ratio- 
nale for this approach is that we predict the most accu- 
rate classification if each of the four intrusion detectors 
(classifiers) is fine-tuned according to the corresponding 
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features. This approach might also be very effective, 
since the four light-weight classifiers can be operated 
in parallel. 


In order to perform the experiment 2), we added normal 
traffic into each attack class to get four data sets: KDD99- 
normaléDoS, KDD99-normaléProbe, KDD99-normalzU2R 
and KDD99-normaléR2L. With each data set, we ran three 
feature selection algorithms: our new CFS-based method, the 
best-first CFS-based and the genetic algorithm CFS-based 
methods. The numbers of selected features and their identi- 
fications are given in Tables // and 111, respectively. We 
then applied the C4.5 and the BayesNet machine learning 
algorithms on each original full set as well as each newly 
obtained data set that includes only the features obtained 
from the feature selection algorithms. We applied 5-fold cross- 
validation on each data set. The classification accuracies are 
reported in Table /V. 


Our new CFS-based method was compared with the best- 
first-CES and genetic-algorithm-CFS methods regarding the 
number of selected features and regarding the classification 
accuracies of 5-fold cross-validation of BayesNet and C4.5 
learning algorithms. Weka tool [13] was used for obtaining 
the results. In order to solve the MO1LP problem, we used 
TOMLAB tool [12]. 


B. Experimental Results 


Table /7 shows the number of features selected by using 
our approach and those selected by using the best-first and 
GA search strategies. The identification of selected features is 
given in Table / 11 (for feature names, see Appendix A). Table 
IV summarizes the classification accuracies of the BayesNet 
and the C4.5 performed on four data sets (see above). 

It can be observed from Table /7 that our CFS-based 
approach selects the smallest number of relevant features in 
comparison with the feature sets selected by the best-first 
and GA search strategies. Especially in some cases, our new 
method compresses the full set of features extremely. For 
example, only one feature was selected out of 41 features of 
the KDD99-normalé¿U2R data set. 

In the Table /V, it can be observed that with our approach 
the average classification accuracies are slightly different from 
the ones obtained by using the best-first search or the genetic 
algorithm. The absolute difference between them does not 
overcome 0.69%. In the case of the C4.5 classifier, we got 
better performance. Even though the gain of classification 
accuracy is not very high compared to other methods, the 
overall gain of the feature selection and classification proce- 
dure lies in significantly improved efficiency and in obtaining 
good classification results with a reduced number of relevant 
features. 

Therefore, based on all the experiments, we can say that in 
general our new method outperforms the best-first-CFS and 
genetic-algorithm-CFS methods by removing much more re- 
dundant features and still keeping the classification accuracies 
or even getting better performances. Thus it can be used to 


find optimal subsets of relevant features by means of the CFS 
measure for intrusion detection systems. 


V. CONCLUSION 


We proposed a new method to get the globally optimal 
subset of relevant features by means of the correlation feature 
selection (CFS) measure. We transformed the CFS optimiza- 
tion problem into a polynomial mixed 0—1 fractional program- 
ming (P01F'P) problem. From this PO1F'P, we then applied 
an improved Chang's method to get a mixed 0 — 1 linear 
programming (M01L.P) problem with linear dependence of 
the numbers of constraints and variables on the number 
of features in the full set. We used the branch-and-bound 
algorithm to solve that M01LP. Experimental results show 
that our approach outperforms the best-first-CFS and genetic- 
algorithm-CFS methods by removing much more redundant 
features and still keeping the classification accuracies or even 
getting better performances. 


APPENDIX A 
NAMES AND IDENTIFICATIONS (ID) OF SELECTED 
FEATURES 


Here we enumerate the features from the original KDD 
CUP”99 data set used in Table 111. 


ID Names 
5 src_bytes 
6 dst_byte 
10 hot 
12 logged_in 
14 root_shell 
22 1s_guest_login 
29 same_srv_rate 
37 | dst_host_srv_diff_host_rate 
41 dst_host_srv_rerror_rate 
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TABLE II 
NUMBER OF SELECTED FEATURES (GA: GENETIC ALGORITHM) 


Data Set Full-set Our-method Best-first GA 

KDD99-normaléDos 41 3 6 11 

KDD99-normalé-Probe 41 6 7 17 

KDD99-normal8¿U2R 41 1 4 8 

KDD99-normaléR2L 41 2 5 8 
TABLE HI 


IDENTIFICATIONS OF SELECTED FEATURES (FOR FEATURE NAMES, SEE APPENDIX A) 


Data Set Identifications 


KDD99-normaléDos 5,6, 12 
KDD099-normaléProbe  5,6,12,29,37,41 
KDD99-normal£U2R 14 
KDD99-normal£R2L 10, 22 


TABLE IV 
CLASSIFICATION ACCURACIES OF C4.5 AND BAYESNET PERFORMED ON KDD CUP”99 DATA SET 

Data Set C4.5 BayesNet 

Full-Set Our-method Best-First GA | Full-Set Ours Best-First GA 
KDD99-normaléDoS 97.80 98.89 96.65 96.09 99.99 98.87 99.09 99.72 
KDD99-normaléProbe 99.98 99.70 99.71 99.89 98.96 97.63 97.65 99.19 
KDD99-normal£U2R 99.97 99.96 99.97 99.95 99.85 99.95 99.97 99.93 
KDD99-normaléR2L 98.70 99.11 99.01 98.86 99.33 98.81 98.95 99.28 


Average 99.11 99.41 98.84 98.69 99.53 98.82 98.91 99.52 


[10] H. Liu, H. Motoda, Computational Methods of Feature Selection, Boca [12] TOMLAB, The optimization environment in MATLAB. http://tomopt. 


Raton: Chapman $ Hall/CRC, 2008. com/tomlab/. 
[11] J. R. Quinlan, C4.5: Programs for Machine Learning, Morgan Kauf- [13] Weka, the data mining software in Java. http://en.wikipedia.org/wiki/ 
mann, 1993. Weka_(machine_learning). 
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Resumen—La cooperación entre los diferentes grupos que 
intervienen en el control y gestión de emergencias no es algo 
trivial. Actualmente esta cooperación se realiza de manera física, 
con comunicaciones verbales e informes que hacen que no sea 
todo lo rápida que cabe esperar. De la mano de la informatización 
de los sistemas de soporte a la emergencia, nace la necesidad 
de compartir la información recogida por los diferentes grupos, 
con el objetivo de aunar esfuerzos. En el presente documento, 
afrontamos la interoperabilidad desde la vertiente de control 
de acceso. Para ello, proponemos un mecanismo de conversión 
de atributos que permite a los miembros de cada grupo de la 
emergencia actuar en calidad de usuarios en los sistemas del resto 
de grupos. Políticas de conversión establecen relaciones entre 
puestos jerárquicos equivalentes de cada grupo. El mecanismo 
contempla el error intrínseco en la conversión así como gestiona 
su transitividad permitiendo una más ágil, sencilla y segura 
cooperación entre todos los actores en una emergencia. 


I.. INTRODUCCIÓN 


A partir del instante en que se produce una emergencia, 
la máxima prioridad es la atención a las víctimas. Para 
ello, diferentes grupos o equipos -como podrían ser equipos 
médicos, el cuerpo de bomberos, protección civil o la policía 
local- se desplazan hasta la zona de la catástrofe con el objetivo 
de atender a los directamente damnificados por ésta y gestionar 
y controlar la situación. Actuaciones como, por ejemplo, la 
rápida identificación del estado de las víctimas -incluyendo 
su localización espacial y su nivel de gravedad-, asegurar el 
área de la catástrofe y la gestión del traslado de las víctimas 
a centros hospitalarios son desplegadas por diferentes grupos. 

Dada la ausencia de un único sistema de soporte y gestión 
de la emergencia, cada grupo de rescate establece su propio 
protocolo de actuación. Sin embargo, con el objetivo de aunar 
esfuerzos para una mejor gestión y control de las catástrofes, 
se crea la necesidad de una integración de la información 
relacionada con la emergencia. De esta manera, el equipo 
médico podría acceder, por ejemplo, a datos pertenecientes 
a los bomberos y relacionados con la extracción de víctimas 
o información, descrita por la policía, sobre el alcance real de 
la emergencia para poder precisar el numero de efectivos que 
se van a necesitar. A pesar de que actualmente se establece 


un punto de coordinación donde se sitúan los coordinadores 
de cada grupo, es precisamente aquí dónde se encuentran los 
cuellos de botella de los flujos de información entre el personal 
de campo. 

El uso de sistemas informatizados de soporte a la emer- 
gencia debería facilitar la interoperabilidad entre grupos. Sin 
embargo, ésta requiere esfuerzos que engloban varia discipli- 
nas como el diseño de interfaces, la interconexión de redes o 
la propia seguridad. En términos exclusivos de autorización, 
el acceso a la información compartida se debe regular para 
evitar comprometer datos de alta sensibilidad. Partiendo de 
la base de que cada grupo de rescate presenta una estructura 
jerárquica interna que regula el nivel de acceso de sus propios 
integrantes, el problema de la interoperabilidad no resulta 
trivial. La información es sensible, máxime cuando se refiera a 
víctimas, y por ello debe ser tratada de manera apropiada. En 
consecuencia, es necesario garantizar que el acceso a los datos 
se haga solamente por aquellas personas autorizadas dada su 
jerarquía. 

En el presente documento proponemos un mecanismo para 
convalidar, de la manera más aproximada posible, las creden- 
ciales que posee un sujeto dentro del grupo al que pertenece 
por credenciales de un grupo cooperante. Esto permite equi- 
parar el nivel de acceso de los integrantes de cada grupo sin 
necesidad de cambiar las políticas de control de acceso de 
cada grupo ni su propio mecanismo de autorización. Dado 
que en general no será posible encontrar una relación directa 
entre el nivel de acceso en diferentes grupos debido a su 
heterogeneidad, el mecanismo propuesto contempla la tasa de 
error en la convalidación. Un umbral de seguridad, ajustable al 
tempo de la emergencia, establecerá la cota máxima aceptable 
del error. Finalmente, cabe destacar que el mecanismo es capaz 
de convalidar atributos de forma transitiva con el objetivo de 
habilitar la interoperabilidad entre grupos aun cuando no exista 
una política de conversión explícitamente definida. 

El resto del artículo se organiza de la manera siguiente: En 
la Sección II se muestra un estado del arte de la propuesta 
centrándose en las aplicaciones para la gestión y seguridad de 
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emergencias. Posteriormente en la Sección III se describe la 
propuesta, mostrando su funcionamiento en la Sección IV a 
través de un ejemplo. En la Sección V se expone una breve 
descripción de la implementación realizada y por último la 
Sección VI concluye el artículo. 


II. ESTADO DEL ARTE 
IT-A. Aplicaciones para la gestión de la emergencia 


Dentro de una emergencia de gran abasto, suelen actuar 
varios equipos de rescate, atención a la víctimas y gestión y 
control de la catástrofe. Cabe remarcar que cada grupo utiliza 
sus propios recursos de coordinación que, actualmente, no 
comparten con los demás. Es posible que el lector pueda llegar 
a pensar que los equipos involucrados en la emergencia no 
utilizan ningún tipo de sistema informatizado y que esto es 
algo futurible, pero no es del todo cierto. Existen proyectos 
como el propuesto por la Generalitat de Catalunya [4], que 
prevé dotar a todos los equipos de bomberos de localizador 
GPS y cámaras para poder ver la emergencia en tiempo real. 
Además, trabajos existentes [11] [3] [10] [13] instan a la 
informatización de algunos de estos equipos. 


II-B. Seguridad 


A nuestro entender, no existen publicaciones que describan 
mecanismos de control de acceso específicos para aplicaciones 
destinadas al control y gestión de grandes emergencias. Sin 
embargo, esquemas clásicos como RBAC [5] pueden ser 
aplicables a estos entornos. Cabe decir que el control de acceso 
en estas situaciones es crucial. Sin embargo, el compromiso 
inherente entre seguridad y flexibilidad adquiere una nueva 
dimensión en este tipo de entornos. Mientras proteger la con- 
fidencialidad de los datos es fundamental, facilitar su acceso 
puede ayudar a salvar vidas. Propuestas como el concepto 
de override [15] otorgan al usuario cierto poder de decisión 
aun cuando sus peticiones de acceso han sido denegadas. De 
forma mas radical, se pueden encontrar propuestas como [14] 
cuyo objetivo es proponer un sistema de control de acceso 
disuasivo en vez de restrictivo. A grandes rasgos, el control 
de acceso disuasivo permite por defecto ejecutar todas las 
acciones auditando a posteriori las posibles violaciones de la 
política. 

La cooperación entre grupos guarda una semejanza inhe- 
rente al control de acceso en entornos multidominio. Actual- 
mente existen algunas propuestas para solucionar problemas 
de control de acceso en este tipo de entornos. Por un lado, 
encontramos la interoperabilidad a nivel de política donde la 
generación de políticas de control de acceso permite compartir 
recursos entre dominios. Dos alternativas de esta solución 
[8] son los llamados dominios libremente asociados y los 
dominios federados. Los primeros se basan en la generación 
de políticas de control de acceso locales [17] que permiten a 
cada dominio dar autorización a usuarios de otros dominios. 
En los segundos, un sólo dominio máster tiene políticas de 
control de acceso global [16] que regulan todas las acciones 
que se realizan en el escenario completo. 


Por otro lado, la interoperabilidad a nivel de atributos se 
basa en encontrar una relación entre los atributos de diferentes 
dominios. Á este nivel, generalmente la interoperabilidad parte 
de la premisa de que se podrán encontrar atributos completa- 
mente equivalentes entre los diferentes dominios, cuando a 
la práctica es bastante improbable. Bajo esta línea, se hallan 
propuestas como un mecanismo de conversión de atributos 
a través de políticas [9] o el uso de ontologías [19] para 
especificar información basada en el contexto bajo el cual se 
pueden definir relaciones entre roles de los diferentes dominios 
que usan RBAC. Otra propuesta relacionada [12] presenta 
un sistema de conversión cuantificada aportando un nivel de 
flexibilidad a la hora de establecer relaciones entre atributos 
que no guardan una equivalencia total. Sin embargo, todas las 
propuestas citadas pecan de falta de escalabilidad, pues cada 
dominio debería poseer tantas políticas de conversión como 
dominios haya en el escenario, menos uno: la que establecería 
una conversión hacia sí mismo. 

De una forma mas tangencial, pero estrechamente relacio- 
nada con la conversión de atributos encontramos propuestas 
como la presentada por Foley [6] donde se proponen medidas 
de similitud entre atributos de un mismo dominio con tal de 
flexibilizar el proceso de autorización. De esta manera, el sis- 
tema debería autorizar acciones si el sujeto presenta un grupo 
de credenciales suficientemente cercanos a los credenciales 
requeridos en la política. 


TIT. PROPUESTA 


En esta sección describimos la propuesta del mecanismo que 
habilita la interoperabilidad de control de acceso en entornos 
de emergencias y que, además, permite definir de una forma 
ágil la frontera inherente entre seguridad y usabilidad en cada 
momento. El mecanismo que proponemos parte de la premisa 
de que generalmente no será posible encontrar atributos en 
diferentes dominios con una equivalencia total y, además, 
ayuda a la escalabilidad habilitando conversiones de atributos 
de forma transitiva. 


IIFA. Conceptos previos 


Previa a la descripción del mecanismo de interoperabilidad, 
se hace necesaria una descripción, en términos de control de 
acceso, de la estructura administrativa de los distintos grupos 
que pretenden cooperar. Dada la heterogeneidad que éstos 
ofrecen, fruto de su independencia, presentamos una visión 
lo suficientemente genérica que engloba gran parte de los 
mecanismos de control de acceso con los que nos encontramos 
en la actualidad, desde sistemas de control de acceso basados 
en identidad hasta RBAC., 

Consideramos que cada grupo representa un dominio de 
seguridad. Cada dominio posee, pues, un conjunto de sujetos 
dentro de él. Los sujetos son entidades activas que aplican un 
conjunto de acciones definidas sobre el conjunto de objetos 
del sistema. Los sujetos del sistema se caracterizan mediante 
atributos. Un atributo es cualquier información relacionada 
con los sujetos, a través de una autoridad central, y que puede 
ser considerada durante la toma de decisiones de acceso. 
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Un mecanismo de control de acceso regula la ejecución de 
acciones por parte de los sujetos sobre los objetos. Diversas 
políticas expresan los atributos cuya posesión, por parte de los 
sujetos, habilita la ejecución de dichas acciones. 


HFB. Habilitando la interoperabilidad 


El mecanismo de interoperabilidad en términos de control 
de acceso que proponemos se fundamenta a nivel de atributo. 
La idea principal es establecer una relación entre los atributos 
de dos dominios distintos, de tal manera que, por ejemplo, 
el jefe de bomberos se pueda equiparar al jefe del personal 
médico de rescate. Para ello se definen políticas de conversión 
de atributos que establecen una relación directa entre los 
atributos de dos dominios. De esta manera, los atributos 
relacionados con un sujeto dentro de un dominio en el cual el 
sujeto no es autóctono se calculan directamente teniendo en 
cuenta los atributos del usuario en su dominio de origen. Una 
vez computados los nuevos atributos del usuario, éste puede 
actuar en el sistema como un usuario mas. Por consiguiente, la 
interoperabilidad no requiere la modificación ni de las políticas 
de control de acceso de cada dominio ni de los mecanismos 
de seguridad. 

Debido a la heterogeneidad en la definición de los atributos 
por parte de los distintos dominios, como norma general no 
será posible definir una relación de equivalencia total entre 
dos atributos. Dicho de otra manera, difícilmente habrá dos 
atributos en dominios diferentes que garanticen un nivel de 
acceso idéntico. El nivel de similitud entre dos atributos denota 
el error intrínseco en la conversión. Para tratar el error de una 
forma natural proponemos la siguiente definición de políticas 
de conversión: 


Definición 1. Las políticas de conversión de atributos entre 
dos dominios A y B, denotadas como CAB, se definen como 
una relación difusa entre los atributos de A y B, tal que: 
Cap : Ax B > [0,1], donde O significa que el grado de 
equivalencia entre dos atributos es nulo y 1 representa el 
máximo grado de similitud. 


Intuitivamente, si Cag(a,b) = 0,8, implica que el atributo 
a definido en el dominio A se considera 0,8 equivalente al 
atributo b definido en B por la propia política Cap. 


TIFC. 


La definición de políticas de conversión de atributos habilita 
la interoperabilidad entre dos grupos en el escenario de la 
emergencia. Por el contrario, se puede dar la situación de 
que no exista ninguna política de conversión de atributos 
directa entre dos grupos distintos que pretenden cooperar. 
Intuitivamente, se puede considerar que si existe una política 
de conversión entre el dominio A y el dominio B, y otra 
política entre el dominio B y el dominio C, los atributos 
del dominio A se pueden convertir en atributos del dominio 
C a través del dominio B. Sin embargo, cabe esperar la 
propagación de los grados de similitud durante la transitividad. 
Ésta no solo beneficia al sistema en términos de escalabilidad, 
fruto de la reducción del número de políticas necesarias para 


Interoperabilidad y transitividad 


convertir los atributos de un dominio hacia el resto, sino que 
aporta agilidad al sistema a la hora de efectuar colaboraciones 
en escenarios donde el tiempo de respuesta es crucial. 

A fin de que la transitividad se pueda ejecutar de manera efi- 
ciente proponemos un mecanismo de composición de políticas 
de conversión C1g y Cc. Dadas dos políticas de conversión, 
definimos su composición como: 


Cac : Capo Co 
Donde el operador de composición [18] se define como: 
CañBoCmo= máxmin(Cag(a, b), CABlDb, c)) 
€ 


Bajo la presencia de diferentes caminos de conversión 
entre dos dominios -es decir, los atributos del dominio 4 
se pueden convertir en atributos del dominio B a través del 
dominio CU” o del dominio D-, el mecanismo de conversión 
procede de la siguiente manera: Primero se encuentran todos 
los caminos de conversión acíclicos entre el dominio origen 
y destino. Acto seguido se calcula la composición de las 
políticas de conversión que forman parte de cada camino. 
Finalmente, se computa la política resultante como la unión 
de las políticas compuestas de cada camino. La unión de n 
políticas se computa escogiendo el valor mayor, posición a 
posición, de cada una de las n políticas. Si no fuese viable, 
en términos computacionales o debido a restricciones de tipo 
temporal, encontrar todos los caminos de conversión entre el 
dominio origen y destino, soluciones sub-optimas pueden ser 
alcanzadas restringiendo el numero de caminos usados en la 
solución. 

Una vez computada la relación transitiva entre el dominio 
origen y destino, la conversión de atributos puede efectuarse 
sobre dicha relación. Nótese que la función no solo establece 
la transitividad en la conversión sino que además propaga el 
error intrínseco de forma natural. 


IIED. El umbral de seguridad 


La interoperabilidad a nivel de atributo entraña que el 
mecanismo de conversión realice asignaciones automáticas de 
atributos a usuarios provenientes de dominios externos. Debido 
a que es el propio dominio destino quien asume el riesgo en 
la conversión, éste se reserva las acciones de comprobación 
necesarias previa asignación de un atributo a un sujeto. 

El nivel de similitud entre dos atributos se debe tener en 
cuenta previamente a la conversión. Un grado de similitud de- 
masiado bajo puede no justificar la conversión de un atributo. 
Para ello definimos el umbral de seguridad 4 como: 


9 > [0, 1] 


El umbral de seguridad ó, presente en cada dominio, estable- 
ce el grado de similitud mínimo por el cual un atributo puede 
ser convertido. De esta manera, si la magnitud de conversión 
es superior o igual a ó, la asignación del atributo convertido 
se hace efectiva. Dicho de otra manera, dado un atributo a 
definido en el dominio A y un atributo b definido en el dominio 
Bb: 
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ar bsiiCagla,b) > 9 


Cabe destacar que el umbral d representa la frontera entre 
flexibilidad y seguridad en el mecanismo propuesto y que éste 
debe ser debidamente ajustado de manera acorde al tempo de 
la emergencia, siendo mas permisivo en las fases que así lo 
requieran. 


IV. EJEMPLO 


En esta sección se expone un breve ejemplo en pro de la 
compresión del mecanismo de interoperabilidad. 


IV-A. Escenario de la emergencia 


Suponga un escenario de emergencia en el que intervienen 
tres grupos. El primer grupo es el grupo de bomberos, que 
presenta la estructura jerárquica mostrada en la Figura 1. El 
segundo grupo es el formado por el Servicio de Emergencias 
Médicas estructurado tal y como se muestra en la Figura 2. 
Por último, el tercer grupo, está formado por la policía local 
del municipio donde ha ocurrido el accidente y presenta la 
estructura mostrada en la Figura 3. 


Inspector (B.I) 


Sub-inspector (B.S) 


Bombero de 


Oficial (B.O) primera (B.BP) 


Cabo (B.C) 


Bombero (B.B) 


Figura 1. Organigrama del cuerpo de bomberos [7]. 
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(VICTOR) 


Columna Sanitaria 
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Figura 2. Organigrama del cuerpo médico [2] simplificado. 


Concejalía (P.C) 


Jefatura (P.J) 


Seguridad 


Ciudadana (P.SC) 


Cabos (P.Ca) 


Agentes (P.A) 


Figura 3. Organigrama del cuerpo de policía [1]. 


Cuadro I 
POLÍTICA DE CONVERSIÓN DE ATRIBUTOS ENTRE EL CUERPO DE 
BOMBEROS Y EL EQUIPO DE EMERGENCIAS MEDICAS 


DG S e v Q | UM | CS 
B.I 0,8 | 0,9 0 0 0 0 0 
B.S 0 0,7 [| 0,9 0 0 0 0 
B.O 0 0 0 1 0,5 0 0 
B.C 0 0 0 0,9 | 0,8 0 0 
B.BP 0 0 0 0 0 1 0,8 
B.B 0 0 0 0 0 0,8 1 


Con el objetivo de agilizar la atención a las víctimas y la 
gestión y control de la emergencia, los tres grupos implicados 
en la catástrofe deciden cooperar. Para ello, habilitan el 
acceso a recursos compartidos entre los diferentes equipos. 
Estos recursos contienen información sobre la clasificación y 
localización de las víctimas o el alcance de la emergencia, 
entre otros datos de importancia. En el Cuadro 1 se muestra 
la política de conversión de atributos entre el cuerpo de 
bomberos y el equipo de emergencias médicas. En el Cuadro 
II, la política de conversión de atributos entre el equipo de 
emergencias médicas y el cuerpo de policía local. 

Mediante las políticas de conversión, se considera que el 
cargo de bombero (B.B) es similar en un 80% al cargo de 
personal de unidad móvil (UM) y 100% similar al puesto 
personal de columna sanitaria (CS). Siempre y cuando este 


Cuadro II 
POLÍTICA DE CONVERSIÓN DE ATRIBUTOS ENTRE EL EQUIPO DE 
EMERGENCIAS MEDICAS Y EL CUERPO DE POLICÍA LOCAL 


PC | PJ | PSC | PCa | PA 

DG 1 0 0 0 0 
0 1 0 0 0 

0 0 1 0 0 

v 0 0 0 0,9 0 
Q 0 0 0 0,8 0 
UM 0 0 0 0 1 
0 0 0 0 il 
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Cuadro HI 
POLÍTICA DE CONVERSIÓN DE ATRIBUTOS ENTRE EL CUERPO DE 
BOMBEROS Y EL CUERPO DE POLICÍA LOCAL, FRUTO DE LA COMPOSICIÓN 
DE LAS POLÍTICAS MOSTRADAS EN LAS CUADROS 1 Y II. 


PC | PJ | PSC | PCa | PA 
B.I 0,8 | 0,9 0 0 0 
B.S 0 0,7 0,9 0 0 
B.O 0 0 0 0,9 0 
B.C 0 0 0 0,9 0 
B.BP 0 0 0 0 1 
B.B 0 0 0 0 1 


valor sea igual o mayor que el umbral de seguridad ó, la 
conversión de los atributos se considera efectiva equiparando 
el nivel de acceso de ambos atributos. 

Si bien es cierto que no existe una relación directa entre 
los atributos del cuerpo de bomberos y los atributos del 
cuerpo de policía local, no es menos cierto que existe una 
relación implícita, representada en el Cuadro III, fruto de la 
composición de las políticas de conversión mostradas en los 
Cuadros 1 y II. 

Mediante la composición de las políticas de conversión, el 
atributo bombero (B.B) guarda una similitud del 100% con 
el atributo agente (P.A). Cabe destacar que, en este caso, la 
conversión de atributos se considerará siempre efectiva, debido 
a que el grado de similitud nunca estará por debajo del umbral 
de seguridad ó. 


V. IMPLEMENTACIÓN 


Se ha desarrollado un prototipo que permite definir los dife- 
rentes dominios de seguridad en el escenario de la emergencia 
así como las políticas de conversión de atributos entre ellos. El 
prototipo no solo permite la conversión de atributos a través 
de políticas explícitamente definidas, sino que es capaz de 
convertir atributos a través de la composición de relaciones. 

Una interfaz gráfica (ver Figura 4) permite definir los 
diferentes dominios de seguridad, así como sus atributos. 
Posteriormente, el prototipo permite definir las políticas de 
conversión de atributos entre los dominios implicados. Una 
vez establecidas las políticas de conversión (ver Figura 5), se 
permite lanzar conversiones de atributos encargándose de la 
composición de políticas si fuese necesario. 


AA Framework of Simulation 
File About 
Domain's Tree 


Policia Local 


> Y 


Selected Domain : 0 


Domains: 3 


Figura 4. Interfaz que muestra las relaciones entre atributos del ejemplo 
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0d 0.0 0.0 0.0 0.0 1.0 

ve 0.0 0.0 0.0 0.0 10 


[Checker ) 
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Figura 5. Relación entre los atributos de los bomberos y la policía. 


VI. CONCLUSIONES 


La cooperación entre los diferentes equipos que trabajan de 
forma concurrente en escenarios de emergencia es esencial pa- 
ra aunar los esfuerzos en la atención a las víctimas, el control 
y la gestión de la emergencia. Sin embargo, la heterogeneidad 
que presentan los grupos a nivel de estructura, jerarquía y 
sistemas de soporte a la emergencia dificulta enormemente 
las tareas de colaboración. En el presente documento hemos 
propuesto un mecanismo de conversión de atributos que, dados 
los atributos otorgados a un sujeto en el grupo de rescate al que 
pertenece, es capaz de convalidarlos en atributos del resto de 
grupos inmersos en el rescate. De esta manera, los usuarios 
son capaces de actuar de forma natural dentro del resto de 
grupos cooperantes. 

El mecanismo propuesto contempla el error intrínseco en 
la convalidación y es capaz de propagarlo en la transitividad 
de las políticas de conversión. De esta manera, es posible 
mantener acotado el error que cada sistema está dispuesto 
a tolerar en cada momento. Además, la transitividad en las 
políticas de conversión es tratada de forma natural ayudando 
a la escalabilidad del mecanismo fruto de la reducción del 
numero de políticas explícitamente definidas en el escenario. 

Se ha desarrollado un prototipo que, previa definición de 
varios dominios en un escenario, permite lanzar conversiones 
de atributos encargándose de computar las políticas transitivas 
si ello fuera necesario. Como trabajo futuro, se propone 
desarrollar el mecanismo en forma de middleware que permita 
la interoperabilidad de los diferentes equipos implicados en la 
emergencia siendo, a su vez, lo menos intrusivo posible. 
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Resumen—En este artículo se propone una técnica biométrica 
basada en firmas en el aire. Los usuarios se autentican realizando 
una firma en el aire con un dispositivo móvil que incluya un 
acelerómetro. Para ello, se propone un sistema en el que todas las 
operaciones necesarias para el proceso de autenticación se llevan 
a cabo en el propio dispositivo, lo cual permite proponer un 
modelo criptobiométrico de liberación de clave. En este modelo, 
hay una clave criptográfica almacenada en el teléfono móvil y 
vinculada a la identidad del usuario propietario del mismo. El 
usuario puede liberar la clave mediante la realización de su firma 
en el aire, y utilizarla como clave criptográfica asociada a su 
identidad, lo cual le puede permitir realizar distintas operaciones 
en Internet que necesitan autenticación de la identidad de la 
persona. Este artículo trata de validar la técnica biométrica en 
la que se basa el modelo criptobiométrico, para ello, se ha creado 
una base de datos de firmas en el aire de 34 usuarios. Además, 
tres falsificadores han tratado de imitar cada una de las firmas 
originales a partir de grabaciones de video. A partir del análisis 
de las muestras originales y falsificaciones se ha obtenido una tasa 
de Equal Error Rate de 2.5 %, consumiendo en todo el proceso 
de autenticación menos de dos segundos. 


I. INTRODUCCIÓN 


Hoy en día se puede acceder a aplicaciones en Internet 
que pueden necesitar autenticación desde la mayoría de dis- 
positivos móviles. Mirar el saldo de una cuenta corriente, 
comprar un producto en una tienda online o realizar ciertas 
Operaciones en sitios web seguros son solo algunos ejemplos 
de operaciones que se pueden realizar desde un móvil con 
acceso a Internet y donde es importante que el usuario sea 
quien dice ser. 

En este contexto móvil, la seguridad suele dejarse en manos 
de contraseñas o códigos PIN que se supone que sólo el 
usuario sabe. Pero esto esconde un gran riesgo ya que las 
contraseñas pueden ser robadas o adivinadas comprometiendo 
la seguridad del sistema. 

El campo de la criptografía coincide con esta problemática, 
ya que la fortaleza de los protocolos criptográficos reside en 
la facilidad para averiguar la clave del usuario. Una vez que 
la clave está comprometida, el sistema no puede considerarse 
seguro. 

La utilización de técnicas biométricas permite solucionar 
estos problemas. Por un lado, el usuario no puede olvidarse 
de su clave, puesto que él mismo es la clave. Por otro lado, 
si la técnica biométrica es suficientemente distintiva, ningún 
usuario va a poder autenticarse en el sistema como si fuera 


otro, manteniendo la clave del usuario original completamente 
segura. 

En la actualidad existen varias investigaciones que tratan de 
unir las técnicas clásicas de biometría en escenarios móviles. 
Por ejemplo, en [1] se presenta un trabajo basado en reconoci- 
miento de iris mediante cámaras en teléfonos móviles, en [2] 
estas cámaras se utilizan para realizar reconocimiento facial, 
en [3] la autenticación se basa en las características de la voz 
extraidas al hablar por teléfono y en [4] se hace una evaluación 
de todas las técnicas de reconocimiento biométrico anteriores 
en teléfonos móviles. 

Asímismo, existen una gran cantidad de trabajos que tratan 
de esquemas de generación o liberación de claves criptográfi- 
cas a partir de patrones biométricos [5] en una rama de inves- 
tigación que está naciendo y que se denomina criptobiometría. 

En este artículo se propone una nueva técnica biometrica 
basada en la realización de la firma en el aire con la mano su- 
jetando un teléfono móvil que integre un acelerómetro. A partir 
de esta técnica se va a proponer un modelo criptobiométrico 
muy sencillo, en el que al autenticarse un usuario se libera 
una clave criptográfica almacenada en el propio dispositivo, de 
tal manera que únicamente el usuario que se haya registrado 
en su teléfono móvil va a poder acceder a realizar ciertas 
transacciones seguras con esa clave privada almacenada. Este 
tipo de modelo criptobiométrico es el más sencillo y puede 
valer de estudio previo para otros modelos más complejos con 
los que se pueden obtener mejores resultados. 

Para estudiar la validez de la técnica, se ha realizado una 
base de datos de 34 usuarios que han realizado una firma o 
gesto identificativo en el aire con un iPhone (que integra un 
acelerómetro). Además, se ha propuesto un método matemáti- 
co de análisis de las señales basado en Programación dinámica, 
así como distintas maneras de fusionar la información de los 
acelerómetros en cada eje. 

Este artículo se divide en la siguientes secciones. En primer 
lugar, en la Sección II se detallan las características de la 
técnica criptobiométrica propuesta en este articulo. A conti- 
nuación, en la Sección II se describe el método matemático 
de análisis de las señales extraídas de las firmas en el aire 
correspondientes a esta técnica. Más adelante, en la Sección 
IV se presenta cómo ha sido la creación de la base de datos 
de firmas en el aire que se ha utilizado para dar soporte 
a los experimentos del artículo. La Sección V incluye una 
explicación del trabajo experimental que se ha llevado a cabo, 
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así como el tiempo y las tasas de error que se han obtenido. 
Finalmente, en la Sección VI se presentan las conclusiones de 
este trabajo junto a unas líneas futuras para seguir investigando 
en el tema. 


II. DESCRIPCIÓN DE LA TÉCNICA CRIPTOBIOMÉTRICA 
PROPUESTA. 


Esta técnica se basa en la realización de una firma en el 
aire con la mano sujetando un teléfono móvil. Para ello, es 
necesario que el teléfono móvil integre un acelerómetro, con 
el que se va a extraer la información de las aceleraciones en el 
eje X, Y y Z de la firma en el aire del usuario. Actualmente 
que la mayoría de los teléfonos móviles que están saliendo 
al mercado satisfacen esta restricción [6]. En particular, este 
trabajo se ha realizado con un iPhone 3G que incluye un 
acelerómetro que recoge las aceleraciones en los tres ejes del 
espacio en un rango de (-2.5g,2.5g). 

La técnica biométrica de reconocimiento de firma en 3D 
puede considerarse como una combinación entre las técnicas 
habituales de comportamiento y físicas. La repetición de una 
firma en el aire no depende únicamente de características 
de comportamiento del usuario como la manera de sujetar 
el teléfono móvil, sino que además influyen una serie de 
características físicas que van a hacer que distintas personas 
puedan repetir un mismo gesto de manera distinta, como 
por ejemplo la longitud del brazo, la capacidad de girar la 
muñeca, el tamaño de la mano, etc. Esta técnica es similar 
al reconocimiento de usuarios por firma manuscrita [7], pero 
adaptada a un entorno de teléfonos móviles, con la ventaja 
de poder utilizarse los tres ejes del espacio, en vez de un 
único plano donde realizar la firma. De hecho, al no ofrecer 
un plano de referencia a posibles falsificadores, la imitación 
de la realización de una firma en el aire es más complicada. 

De igual manera, esta técnica tiene aspectos comunes con 
las técnicas de reconocimiento de gestos, pero el enfoque es 
radicalmente distinto. Las técnicas de reconocimiento gestua- 
les intentan reconocer un mismo gesto realizado por muchas 
personas distintas, que lo pueden hacer de manera diferente 
para después realizar una acción común a todos y en respuesta 
a ese gesto [8]. El enfoque en la técnica biométrica es 
diferenciar a la persona que realiza el gesto, así pues, si 
dos personas realizan el mismo gesto (o firma) en el aire, el 
sistema ha de ser capaz de identificar que los gestos, a pesar de 
su parecido, son distintos, pues corresponden a dos personas 
diferentes. 

En esta propuesta, la extracción de características se rea- 
liza directamente en el propio móvil, sin ningún dispositivo 
adicional. Además, se pretende que todo el proceso de au- 
tenticación se realice también dentro del teléfono, para evitar 
los compromisos de seguridad en las conexiones con cualquier 
servidor externo. De esta manera, ejecutar todos los algoritmos 
involucrados en el proceso dentro del propio dispositivo móvil 
ofrece una gran cantidad de ventajas: 

= El usuario no necesita gastarse más dinero en otros dis- 

positivos, ya que únicamente necesita su propio teléfono 
móvil que ya tiene. 


= Las posibilidades de ataque al sistema se reducen, ya 
que ninguna clave ni patrón sale fuera del dispositivo, 
ofreciendo una solución “Match on Card”[9]. 

= El sistema es resistente a ataques o caídas en las comu- 
nicaciones con un posible servidor externo que realice el 
proceso de autenticación. 

= Esta configuración permite adoptar soluciones de cripto- 
biometría, en el que la realización de una firma pueda 
generar, liberar o descifrar una clave asociada al usuario 
que se encuentra almacenada en el móvil, y que sólo él 
puede utilizar para realizar acciones que necesiten estar 
seguras de su identidad. 


El proceso de autenticación de un usuario según esta técnica 
biométrica puede realizarse en un dispositivo móvil gracias 
al incremento de potencia de los microprocesadores de los 
mismos, que permiten ejecutar los algoritmos involucrados 
en una cantidad de tiempo razonables, logrando así alcanzar 
también el requisito de tiempo “real”. 

Por otro lado, la realización de todo el proceso de autentica- 
ción en el propio dispositivo móvil, permite aplicar de manera 
sencilla un modelo criptobiométrico de liberación de clave tras 
autenticación. De este modo, el teléfono móvil puede tener 
una clave criptográfica asociada a la identidad del usuario 
propietario del dispositivo. Para acceder a la clave y utilizarla 
en cualquier aplicación que necesite autenticación, el usuario 
ha de repetir su firma en el aire, asegurando así su identidad. 


III. MÉTODO MATEMÁTICO DE ANÁLISIS 


En este artículo se ha desarrollado un algoritmo basado 
en Programación Dinámica para analizar las diferencias entre 
señales para averiguar si una muestra se corresponde con la 
original o no. Este algoritmo propone buscar la alineación 
óptima de las dos señales que se quieren comparar, incluyendo 
una serie de ceros e interpolando las señales para tratar de 
maximizar una función de puntuación concreta [10]. Como 
consecuencia de este algoritmo, la longitud de las señales 
alineadas puede llegar a duplicarse. Una vez realizado el 
alineamiento óptimo de las señales, se calcula la distancia 
Euclídea entre cada par de señales, para cuantificar la dife- 
rencia en la realización de las firmas en el aire. 

Este algoritmo incluye una función borrosa en la función 
de la puntuación que hay que maximizar representando la 
variabilidad con la que el propio usuario es capaz de repetir su 
firma en el aire. Esta ecuación de la puntuación del algoritmo 
se muestra en la Ecuación 1: 


Sij=1 T h 
8 = MAX 4 Sia A (1) 
Simi, Y h 


donde h es una constante conocida en la literatura como 
“gap penalty” [11] y cuyo valor se obtiene al maximizar el 
rendimiento global del sistema. El valor seleccionado es de 
h = 0,4, que coincide con un 12.5% del rango de valores 
posibles de aceleraciones que el acelerómetro es capaz de 
extraer. Por otro lado, A es la función borrosa de decisión 
que representa una distribución Gaussiana: 
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Aso 2) 
donde yu y x son los valores de los puntos previos (¿—1,j—1) 
en base a los que se calcula la puntuación de los nuevos 
puntos (+, ¿). Esta función introduce una cierta borrosidad en la 
transición de un punto a otro que se refleja en la representación 
global de la variabilidad de las distintas realizaciones de un 
gesto por un mismo usuario. Finalmente, d es una constate 
que representa hasta qué punto dos valores son similares. En 
este trabajo se ha elegido dv = 0,250 representando que dos 
puntos son iguales en un entorno del 10 % del rango de todos 
los puntos posibles de aceleración. En este tipo de técnica 
biométrica, un usuario no va a ser capaz de repetir al 100 % 
su firma en el aire; siempre existirá una pequeña variabilidad 
en la velocidad en la que el usuario realiza alguna parte de 
su firma, en la manera de realizar los giros y movimientos 
de su firmo o en el modo de agarrar el teléfono móvil. 
Gracias al método de análisis propuesto en esta Sección, estas 
pequeñas desviaciones pueden ser corregidas con facilidad sin 
compensar otras diferencias más notorias provenientes de las 
posibles falsificaciones de firmas por otros usuarios. 

En la Sección V se presentarán las tasas de error obtenidas 
al utilizar este método para reconocer las firmas en el aire 
originales de distintos usuarios respecto a los intentos de 
falsificación de otros usuarios. 

IV. DESCRIPCIÓN DE LA BASE DE DATOS UTILIZADA 


Los experimentos realizados en este artículo se han desarro- 
llado a partir de una base de datos propietaria creada específi- 
camente para este cometido. Han participado 34 usuarios que 
han realizado su firma en el aire y 3 falsificadores que han 
estudiado cada una de las firmas originales y han tratado de 
reproducirlas lo más fielmente posible. La base de datos final 
se ha obtenido en dos sesiones distintas: 

En la primera sesión, cada usuario ha inventado un gesto 
identificativo y lo ha realizado en el aire con un teléfono móvil 
que integra un acelerómetro. Este gesto se corresponde con la 
firma en el aire que cada usuario ha seleccionado para utilizar 
en esta técnica biométrica propuesta. Para la primera sesión 34 
usuarios diferentes (de edades entre 19 y 60 años, 15 mujeres 
y 19 hombres) han repetido 7 veces su firma en el aire, con 
intervalos de 10 segundos entre cada firma para reducir la 
dependencia entre muestras. Además, todas estas sesiones han 
sido grabadas en vídeo para que en la segunda sesión otros 
usuarios pudieran tratar de falsificar las firmas originales. 

Para la toma de muestras y la extracción de características se 
ha desarrollado una aplicación para el iPhone 3G que registra 
las aceleraciones en los ejes X, Y y Z en la ejecución del 
gesto a una frecuencia de muestreo de 10ms, suficiente para 
obtener señales representativas del movimiento de la mano en 
el aire [12]. 

Al finalizar esta primera sesión, todos los voluntarios han 
respondido una encuesta para evaluar (1 muy bien - 5 muy 
mal) distintos aspectos de la técnica biométrica basada en 
reconocimiento de firmas en el aire propuestas. Los resultados 
se presentan en la Tabla 1: 


Pregunta Media | Moda | Desviación estándar 
Facilidad para inventar 
una firma en el aire ZL 2 0.65 
Facilidad para repetir 
una firma en el aire 1.9 2 0.45 
Colectividad 
de la técnica 1.9 il 0.71 
Aceptabilidad 
de la técnica 2.7 2 0.85 
Cuadro I 


RESPUESTAS DE LOS VOLUNTARIOS A DIFERENTES ASPECTOS PARA 
VALIDAR LA TÉCNICA BIOMÉTRICA BASADA EN RECONOCIMIENTO DE 
FIRMAS EN EL AIRE DESDE EL PUNTO DE VISTA DE LA EXPERIENCIA DEL 
USUARIO. 


A partir de estas respuestas se puede inferir que para 
los usuarios ha sido bastante sencillo inventar y repetir una 
firma en el aire con un dispositivo móvil. Debido a que los 
datos biométricos se adquieren de manera no intrusiva, los 
usuarios han evaluado la colectividad [13] de la técnica como 
buena. Además, los usuarios se sienten seguros y cómodos 
cuando las características biométricas se extraen, por lo que 
la aceptabilidad de la técnica recibe también una buena nota. 

Además, se les ha solicitado a los voluntarios que comparen 
la confianza que les ofrece esta técnica de reconocimiento de 
firmas en el aire respecto a otras técnicas biométricas como 
iris, cara, mano, huella dactilar y firma manuscrita. En media, 
los participantes han evaluado la confianza de la firma en el 
aire por encima de la firma manuscrita, ya que consideran 
que es más difícil de falsificar puesto que no hay un plano 
de referencia (papel) donde poder observar con facilidad los 
trazos de la firma. Además, la confianza que ofrece esta técnica 
a los usuarios es menor, pero próxima, a las técnicas de 
reconocimiento de cara y geometría de mano, y muy lejana a 
la confianza en las técnicas más robustas como iris y huella 
dactilar. 

Por otro lado, a partir del estudio de los videos grabados 
en la sesión previa se ha realizado una segunda sesión para 
obtener muestras de intentos de falsificación de firmas ori- 
ginales. En esta sesión, tres usuarios han intentado falsificar 
cada una de las 34 firmas en el aire originales estudiando con 
detenimiento cada uno de los videos de la sesión anterior. Cada 
falsificador ha realizado 7 intentos de imitación de cada firma 
original. 

Como resultado de ambas sesiones, se ha obtenido una base 
de datos de 238 muestras de gestos originales (34 usuarios x 
7 repeticiones) y 714 falsificaciones (34 usuarios originales x 
3 falsificadores x 7 intentos). A partir de esta base de datos, 
en la siguiente Sección se explicarán los experimentos que se 
han realizado y las tasas de error obtenidas para validar la 
fiabilidad de la técnica biométrica propuesta. 


V. RESULTADOS EXPERIMENTALES 


En esta sección se presentan los experimentos que se han 
realizado analizando las señales obtenidas a partir de la base 
de datos de firmas en el aire creada mediante el método 
matemático propuesto en la Sección III. 

Para medir la fiabilidad del sistema biométrico, se utilizarán 
las tasas de error típicas en biometría [14]: la tasa de error de 
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falsos positivos O aceptación de usuarios fraudulentos que han 
conseguido falsificar la firma de un usuario original (FAR, 
False Acceptance Rate), la tasa de error de falsos negativos o 
usuarios que a pesar de realizar su firma original el sistema ha 
rechazado (FRR, False Rejection Rate), y el punto donde se 
cortan las dos tasas anteriores, denominado EER (Equal Error 
Rate). Una tasa de EER suficientemente baja va a permitir 
utilizar esta técnica biométrica para la liberación de claves 
criptográficas que puedan estar en el teléfono móvil y sólo el 
usuario autenticado puede utilizar para asegurar su identidad 
en otras aplicaciones. 

Para ello, se han seleccionado aleatoriamente tres muestras 
de cada gesto para conformar el patrón de la firma en el 
aire. Las otras cuatro muestras originales van a representar 
intentos originales de autenticación del usuario, que el sistema 
debe de aceptarlos. Todas las muestras de falsificaciones se 
consideran ataques al sistema que deben ser rechazados. Por 
tanto, las tasas de error EER se han calculado a partir de 136 
muestras originales (34 usuarios x 4 muestras de acceso) y 
714 muestras de impostores (34 usuarios x 3 falsificadores x 
7 muestras). 

Para poder evaluar esta técnica como potente, es imprescin- 
dible que las tasas de EER sean suficientemente bajas, pero 
también que el tiempo necesario para llevar a cabo la ejecución 
de los algoritmos involucrados en el proceso sea razonable- 
mente corto. De acuerdo con esta idea, hay que remarcar 
que el tiempo de ejecución del algoritmo propuesto crece 
exponencialmente con la longitud de las señales, mientras que 
el incremento del número de ejecuciones del algoritmo con 
señales de longitud constante crece de manera lineal. 

Cada firma en el aire almacena información sobre las 
aceleraciones en cada eje X, Y y Z producidas en la ejecución 
de la firma. Para fusionar estas tres señales se han probado 
tres estrategias de fusión multibiométricas diferentes, cada 
una en un nivel de la estructura biométrica [15]: en el nivel 
decisión (“Decision Level”), en el nivel de extracción de 
características (“Feature Extraction”) o en el nivel de compa- 
ración (“Matching score”). En este artículo sólo se explicará la 
primera estrategia puesto que es la que ha producido mejores 
resultados. 

Fusionar la información de las tres señales de aceleración 
de cada señal a nivel de decisión implica ejecutar en paralelo, 
pero de manera separada, el algoritmo de alineamiento para 
cada uno de los ejes y finalmente, calcular un único valor 
que cuantifique la diferencia entre las dos firmas a partir de 
los valores obtenidos en cada uno de los ejes. El valor de 
comparación para dos firmas en el aire A y B de longitud L 
se calcula según la Ecuación 3: 


a+ + AB 
3 


(3) 


dAB= 


donde d% y, dy y y dí g son los valores obtenidos al 
alinear las señales en los ejes x, y y z de manera separada y 
calculando su distancia Euclídea según la Ecuación 4: 


Figura 1. Equal Error Rate Resultante 


EER = 2.5% 


Error 
o 
o 
A 


Comparison metric 


2L 
2, = Y (Ars — Ba) (4) 
¿=1 

donde A y Bf son las señales resultado de alinear las 
señales A y B en el eje e. Debido a que la longitud de las 
señales puede duplicarse en el algoritmo de alineamiento, el 
valor resultante d% yg para cada eje e se obtiene calculando las 
diferencias entre cada punto a lo largo de toda la longitud de 
las señales 2£. 

De acuerdo al escenario de fusión de información propuesto, 
el algoritmo de alineamiento se ejecuta tres veces, una para 
cada eje de manera separada. Los resultados del algoritmo 
se fusionan a nivel de decisión, calculando la media de los 
resultados de cada eje. Con estas condiciones, se ha obtenido 
un valor de EER (Equal Error Rate) de 2.5 % (Figura 1). 

Sea Tp el tiempo de ejecución del algoritmo de alineamien- 
to, que es la tarea que más tarda dentro del proceso de auten- 
ticación. Entonces, el tiempo consumido en este experimento 
es equivalente a tres veces la ejecución del algoritmo con dos 
señales de longitud L (3Tp(L)). Este tiempo se ha medido 
en un dispositivo móvil (¡Phone 3G) resultando ser de 1.51 
segundos en media. El cálculo de este tiempo se ha obtenido 
como la media de la ejecución del algoritmo con señales de 
600 puntos por cada eje (una firma que dura seis segundos 
a una frecuencia de muestreo de 100 Hz) durante diez veces 
seguidas. 

VI. CONCLUSIONES Y LÍNEAS FUTURAS 


En este artículo se ha propuesto una nueva técnica cripto- 
biométrica para liberar una clave que se encuentra almacenada 
en un teléfono móvil mediante la realización de una firma en 
el aire con el mismo. Para ello, es necesario que el dispositivo 
incluya un acelerómetro para así poder extraer las aceleracio- 
nes en la ejecución de la firma. Con este sistema propuesto, 
todas las operaciones necesarias para la autenticación del 
usuario se procesan, en un tiempo razonable, dentro del propio 
teléfono móvil, sin necesidad de ningún dispositivo externo 
que encarecen el sistema e incluyen una comunicación que 
podría ser fuente de inseguridades. 
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Para estudiar la validez de esta técnica, se ha creado una 
base de datos de firmas biométricas en el aire. Para ello, 34 
usuarios han inventado y repetido una firma en el aire con 
un teléfono móvil que integraba un acelerómetro. Además, en 
otra sesión, tres falsificadores han intentado imitar los gestos 
originales a partir de grabaciones de video. Los participantes 
en la creación de la base de datos han evaluado positivamente 
la facilidad, aceptabilidad, colectividad y confianza que les 
transmite la técnica biométrica propuesta. 

A partir de la información de la técnica biométrica, se han 
estudiado diferentes escenarios de fusión de la información, 
obteniéndose las menores tasas de error cuando la fusión se 
llevaba a cabo a nivel de decisión. Para ello, se ha estudiado 
la tasa de Error de Falso Rechazo (FRR) a partir de las 
muestras originales y la tasa de Error de Falsa Aceptación 
(FAR) mediante las muestras de falsificaciones de los gestos 
originales. Como resultado de la intersección de las dos 
gráficas, se obtiene el valor final de Error (EER) de 2.5%, 
que valida la seguridad de la técnica. 

Una vez realizada la autenticación del usuario, la clave 
almacenada en el teléfono móvil y ligada a un único usuario 
puede ser liberada, permitiéndole al mismo la utilización de 
la misma para conectarse a aplicaciones que necesitan la 
seguridad de que el usuario es quien dice ser. 

Además, se ha desarrollado una aplicación prototipo en un 
teléfono móvil que incluye un acelerómetro, desde el que 
directamente se ha medido que el proceso de autenticación 
propuesto en este artículo requiere 1.51 segundos. Teniendo 
en cuenta el tiempo en comunicarte con los servidores Web 
en dispositivos móviles o el tiempo en realizar una transacción 
por Internet desde un teléfono móvil, el tiempo obtenido en 
este estudio es perfectamente asumible por un usuario. 

Como líneas de trabajo futuro en este tema aparece la 
posibilidad de aplicar otros esquemas criptobiométricas más 
complejos a la técnica biométrica de reconocimiento mediante 
firma en el aire. Estudiando distintas características intrínsecas 
a las señales de aceleración en cada eje en la repetición 
de una firma, podría generarse automáticamente una clave 
criptográfica, mejorando de en gran medida el modelo puesto 
que ya no sería necesario almacenar una clave ligada a un 
usuario en su teléfono, sino que el usuario mismo sería capaz 
de generarla cuando la necesitara realizando su firma. 
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Resumen—El paradigma de los agentes móviles representa 
una de las tecnologías más prometedoras para los escenarios 
de Ambientes Inteligentes donde un gran numero de dispositivos 
interactúan. Desafortunadamente, la carencia en los mecanismos 
de seguridad, tanto en la aplicación de estos mecanismos como en 
su usabilidad, está dificultando la aplicación de este paradigma a 
las aplicaciones del mundo real. En el artículo que presentamos a 
continuación mostramos una solución software para la protección 
de sistemas multiagentes. Nuestra propuesta está enfocada en un 
modelo de agentes cooperativos y se basa en la computación 
protegida. Por último, uno de los atractivos más importantes 
del trabajo realizado es la facilidad de uso para aquellos 
desarrolladores de sistemas basados en agentes que no sean 
expertos en seguridad. 


I. INTRODUCCIÓN 


En el área de los sistemas de información, la seguridad es 
uno de los aspectos en los que se requiere mayor esfuerzo. 
Con el auge que tanto en la década de los 90 como en los úl- 
timos años han experimentado los sistemas distribuidos, se ha 
producido asimismo un aumento de los ataques informáticos 
y, por tanto, de los sistemas de protección. 

El presente artículo se centra en los sistemas de agentes 
móviles inteligentes y en los esquemas de seguridad mutua 
estática [9]. 

Los primeros trabajos sobre agentes software surgen a 
mediado de los años 70 de la mano de Carl Hewitt [4]. 
Hewitt creó un modelo de agente (llamado actor) al que 
define como un objeto autónomo que interacciona y se ejecuta 
concurrentemente y que posee un estado interno y capacidad 
de comunicación. 

En la actualidad existen multitud de variantes de agentes 
software dependiendo de sus características, habilidades o 
propiedades. Nuestro trabajo va enfocado a un tipo de agentes 
software conocido como agentes móviles y a su seguridad. 

Los agentes móviles son implementaciones de programas 
remotos, es decir, programas que se desarrollan en una 
máquina y se distribuyen en otras máquinas para ejecutarse 
posteriormente [10]. La capacidad de migración provoca difer- 
entes riesgos de seguridad y hace necesario que se controlen 
los siguientes aspectos: 

= protección de la máquina contra los agentes 

= protección de los agentes contra la máquina 

= protección de la red. 

Existen diversas propuestas de protección para cada uno 
de los puntos descritos anteriormente, nosotros sólo hemos 


tratado las relacionadas con la protección de los agentes contra 
la máquina. En este caso, se ha de suponer que no se puede 
confiar en las máquinas(agencias) a las que los agentes móviles 
pueden migrar, lo cual provoca riesgos de seguridad en todo 
el sistema multiagente. 

Una de las estrategias para solventar estos problemas y 
añadir un mayor grado de seguridad al sistema multagente 
se basa en las ideas de la computación protegida [8]. Dicha 
idea, propone dividir el código en dos o más partes, algunas de 
estas partes se ejecutarán en un procesador seguro y confiable, 
mientras que las otras partes podrán ejecutarse en cualquier 
procesador. 

Al aplicar esta estrategia de seguridad a los sistemas multi- 
agentes se logra un modelo en el que cada agente colabora 
con uno o más agentes remotos, los cuales a su vez se 
ejecutan en diferentes agencias confiables o no. Para que 
un ataque sea efectivo necesita la cooperación de todas las 
agencias. Podemos distinguir dos esquemas diferentes dentro 
de la protección mutua: 


= protección mutua estática, que es la que utilizamos en 
este trabajo y 
= protección mutua dinámica. 


Gracias a los trabajos de investigación desarrollado por 
miembros de la Universidad de Málaga se han creado las 
librerías necesarias que implementan las ideas de protección 
mutua. Siguiendo esta linea de investigación nos planteamos 
el objetivo de crear una herramienta que, utilizando dichas 
librerías, sea capaz de generar automáticamente un sistema 
multiagente con seguridad mutua estática a partir de un sistema 
multiagente sin seguridad. Esto nos permitiría comprobar fácil- 
mente el funcionamiento y la eficacia del sistema dependiendo 
de los parámetros que determinan el nivel de seguridad y 
escogiendo en cada caso el más apropiado para el sistema 
multiagente original. 

El presente documento está organizado de la siguiente 
forma: En la sección 2 comentamos los trabajos relaciona- 
dos, introduciéndonos en los sistemas multiagentes móviles, 
plataforma Jade y esquemas de seguridad. La sección 3 se 
centra en el problema principal de este articulo, generar 
automáticamente un sistema multiagente con seguridad mutua 
estática. Describimos en la sección 4 la arquitectura y carac- 
terísticas del software desarrollado y por último introducimos 
una sección con las conclusiones del trabajo. 
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TI. TRABAJOS RELACIONADOS 


Anteriormente mencionamos la existencia de diferentes 
propuestas para la ejecución segura de software. Vamos a 
centrarnos en las técnicas que establecen una protección 
bidireccional. Entre ellas, la llamada Computación Confiable, 
que se basa en crear un sistema en el que la seguridad de todos 
los elementos se compruebe a partir de un componente con- 
fiable, frecuentemente construido en hardware [11]. A partir 
de esta idea se construyó un modelo alternativo denominado 
Computación Protegida [8], [7]. Dicha propuesta se basa en 
la idea de dividir el código en dos o más partes. Algunas 
de ellas se ejecutarán en un procesador seguro, mientras que 
otras se ejecutarán en un procesador cualquiera. De forma que 
no sea posible ejecutar la aplicación sin la colaboración del 
procesador confiable. 

La división del código en partes mutuamente dependiente 
debe conseguir que: 


= La parte pública no sea de utilidad para obtener infor- 
mación de la protegida 

= Un trazado de la comunicación entre ambas partes no 
pueda usarse para obtener información de la parte prote- 
gida. 


cd AgentSociety » 
1: Agency 2: Agency 
Runs in Runs in 
Protects 
A: Agent C: Agent 
Proects Prolects 
Protects 
B: Agent D: Agent 
Runsin Runsin V 
3: Agency 4: Agency 


Figura 1. Una sociedad de agentes con protección mutua. 


Este esquema de seguridad puede ser usado en distintos 
tipos de escenarios. Por ejemplo, un sistema multiagente con 
agentes móviles que se trasladen a diferentes agencias (no 
confiables) para llevar a cabo algunas tareas colaborativas. 
Debido al desconocimiento de las agencias no se puede 
garantizar la correcta ejecución del agente y su integridad, 
por ello el principal objetivo en este escenario será proteger 
a los propios agentes frente a posibles agencias maliciosas. 
En la Figura 1 podemos observar como se relacionan entre sí 
ejecutándose en diferentes agencias. Los agentes se protegerán 
unos a otros y por turnos. En esta configuración un ataque 
requerirá la cooperación de todas las agencias. Para este 
ejemplo específico es posible que las partes protegidas de un 
agente estén incluidas directamente en otros agentes, lo que 


dificulta la posibilidad de que se produzca la transmisión de 
las secciones de código protegido por la red. 

Vamos a destacar dos esquemas diferentes a la hora de 
aplicar esta estrategia de seguridad. En la primera, a la que 
llamaremos protección mutua estática, la colaboración entre 
los agentes está predefinida. Esto significa que cada agente 
posee el código privado de uno o más agentes con los que 
colabora. Por otro lado tenemos la protección mutua dinámica 
que hace posible que los agentes del sistema funcionen como 
coprocesadores seguros para los demás agentes. En este caso, 
la interacción entre los agentes no está predefinida. 


Ir-A. Protección mutua estática 


Para el desarrollo de nuestra herramienta nos hemos centra- 
do en la protección mutua estática. Para este tipo de estrategia 
las partes protegidas de un agente están directamente incluidas 
en él o en los agentes protectores. En la Figura 2 podemos 
observar una abstracción de la un agente con protección mutua 
estática. 


Figura 2. Estructura de un agente con protección mutua estática. 


La gran ventaja de esta estrategia es que incrementa el 
rendimiento del sistema gracias a que no se producen trasmi- 
siones de código protegido a través de la red. Por el contrario, 
su gran limitación exige que el sistema sea configurado 
estáticamente y los agentes deban ser protegidos antes de su 
ejecución. 

Estos serían los trabajos teóricos en los que se basa nuestra 
aplicación, pero falta una base práctica y herramientas que 
implementen todos estos conceptos. La plataforma para tra- 
bajar con agentes la conseguimos gracias a JADE [12] y con 
la librería SecureAgent le añadimos el esquema de seguridad 
mutua estática. 


II-B. La librería SecureA gent 


La implementación de seguridad mutua estática que uti- 
lizamos ha sido desarrollada por Manuel Jiménez en su 
proyecto fin de carrera bajo la tutela de Antonio Maña y 
Antonio Muñoz. El lector puede encontrar más detalles de 
la librería en [5]. 

Para construir un sistema multiagente con las propiedades y 
funcionalidades de seguridad mutua estática, basta con heredar 
de la clase SecureA gent. Los agentes que heredan de esta clase 
poseen comportamientos que se encargan de realizar las tareas 
de protección. Al utilizar la librería no es necesario conocer 
la función de cada uno de los comportamientos. 

Además de los comportamientos, es necesario mencionar 
la interfaz PrivateCode. Es una interfaz en la que sólo se 
define un método. De esta forma, el fragmento de código 
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privado de cada agente irá en el método execute() de la 
clase específica que implemente la interfaz PrivateCode. El 
agente deberá realizar una llamada al método execute() con 
los parámetros correspondientes para comenzar la ejecución 
del código privado. 
En la Figura 3 podemos ver como sería el intercambio de 
mensajes entre dos agentes para realizar una ejecución segura. 
sn 
1: ACLWES: 


execute-ny-private-code; 


| 2: AU Vessage(send-me-the-args) | 


1 1 
¡ 3; AQLVessage(Object:Aras) ¡ 


4: AQLVessage(Object Result) 


Figura 3. Intercambio de mensajes para una ejecución segura. 


III. NUESTRA SOLUCIÓN 


Antes de explicar la herramienta que hemos desarrollado 
vamos a hacer un resumen de la situación. Por un lado tenemos 
un sistema de agentes móviles inteligentes y la plataforma de 
agentes Jade, y por otro lado contamos con la estrategia de 
seguridad mutua estática y la librería SecureAgent con la que 
conseguimos un sistema de agentes seguros. 

Por lo tanto, a partir del sistema de agentes móviles y 
utilizando las librerías de seguridad mutua estática el pro- 
gramador debe ser capaz de crear un sistema multiagente 
equivalente al inicial pero con seguridad incorporada. Este 
proceso implica conocer las librerías, reprogramar las clases 
y seleccionar los datos y código que queremos proteger. 

Quizás, realizar estos pasos 1 o 2 veces no sería muy 
tedioso, pero es poco práctico. Imaginemos que después de 
trabajar unos horas realizando esta tarea carguemos los nuevos 
agentes para comprobar su funcionamiento y comprobemos 
que su eficiencia es baja o que el nivel de seguridad no es el 
adecuado. 

Lo interesante es poder cambiar rápidamente la configu- 
ración de seguridad, ver los resultados y decidir si son los 
más adecuados para el sistema en cuestión. Por todo ello, el 
objetivo de nuestra herramienta es agilizar y automatizar todo 
este proceso. 

Con el escenario inicial y el objetivo principal perfectamente 
definido comenzamos a estructurar los requisitos del sistema y 
a seleccionar las herramientas necesarias. El esquema general 
del sistema lo podemos ver en la Figura 4. 

Como podemos observar el punto de partida o entradas de 
nuestra aplicación son los agentes sin seguridad que vendrán 


Secure 
Agents 


El e 


Agents witout 
security 


Software Tool 


Figura 4. Arquitectura del generador de agentes seguros. 


definidos por unas clases java (archivos .class). Las salidas 
del programa son estos mismos agentes pero con seguridad 
incorporada y de igual forma definidos por unas clases java. 

Por lo tanto el trabajo que tenemos que realizar es leer, 
analizar, modificar y crear archivos .class. Para ello necesita- 
mos una herramienta que nos permita trabajar cómodamente 
con este tipo de ficheros. Existen varias herramientas que 
tienen estas características como BCel [3], Javassist [1] o 
ASM [2], nosotros optamos por la primera ya que cuenta 
con bastante documentación, está desarrollada por Apache 
Software Foundation, lo cual nos da cierta confianza y es 
multi-plataforma al estar escrita en java. 


IIFA. Byte Code Engineering Library (BCEL) 


Un fichero .class tiene una estructura interna bastante com- 
pleja y difícil de manejar como se muestra en la Figura 5. Sus 
numerosas referencias y el bajo nivel del código que contiene 
hacen de su análisis y creación una labor muy tediosa. 


Header | 


| ConstantMethodRet 
+ *printin" 
Constant pool "(Ljava/lang/String;)V" 
"javafo/PrintStream" 
ConstantFieldref 
"aVariable”" 
Access rights "[Ljavalang/Object;" | 
"HelloWorld" | 
implemented interfaces ConstantClass | 
"javaño/PrintStream" 
Fields ConstantString 
=>] "Hello, world" 
Methods == 
[ ] getstatic java.lang.System.o: 
lde "Hello, world” | 
invokevirtual java.io.PrintStream.println 
¡a y ) 
Class attributes 


HelloWorld.class 


Figura 5. Formato de un archivo .class. 


Para trabajar con estos ficheros usamos Bcel, un proyecto 
desarrollado por Apache Software Foundation y que nos ofrece 
una amplia API que podemos dividir en tres partes: 


= Un paquete que contiene clases que describen las 
propiedades “estáticas” de los ficheros de clase*. Las 
clases deben ser utilizadas para leer y escribir ficheros 
de clase desde o hacia un archivo. Esto es especialmente 
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útil para analizar clases Java sin tener el código fuente a 
mano. La clase principal de este paquete es JavaClass. 
= Un paquete para generar O modificar dinámicamente 
ficheros de clase. Puede ser utilizado para añadir o 
analizar código de los ficheros de clase, etc. 

= Varios códigos de ejemplo y utilidades, como un visor de 
ficheros de clase, una herramienta para convertir fichero 
de clase a HTML y al lenguaje ensamblador Jasmin. 


El componente estático consta de una serie de clases que 
modelan la estructura interna de un fichero .class. La clase 
principal, denominada JavaClass, se construye a partir de un 
fichero .class y ofrece multitud de funciones para navegar 
por sus diferentes componentes, campos, métodos, variables 
locales, clases internas, etc. 

Además proporciona diversos patrones para el control y el 
análisis de los elementos como pueden ser el patrón visitante 
o el observador. En nuestro caso, y para el análisis de las 
instrucciones, el patrón visitante ha sido de gran utilidad. La 
jerarquía de instrucciones bytecode se ajusta muy bien a este 
patrón y te permite organizar cómodamente qué hacer con cada 
una de ellas. Por ejemplo, en una instrucción LOAD/STORE 
será necesario conocer qué campo se quiere leer o, en una 
INVOKE el método al que se invoca. 

Este componente estático no nos permite modificar ni crear 
nuevos ficheros .class que es primordial para nuestro proyecto. 
Para ello hacemos uso del componente dinámico. Su clase 
principal es ClassGen que nos otorga la posibilidad de crear 
una clase vacía e ir añadiéndole dinámicamente todos los 
componentes que deseemos, para finalmente guardarla como 
un archivo .class. 

Por lo tanto ya tenemos la herramienta que nos va a permitir 
por una lado analizar los archivos de entrada que representan a 
los agentes sin protección y por otro generar las nuevas clases 
que representaran a los agentes seguros utilizando la librería 
SecureA gent. 


IV. ARQUITECTURA 


En esta sección vamos a mostrar con mayor detalles las 
características y el funcionamiento de la herramienta que 
hemos desarrollado. Como comentamos anteriormente el obje- 
tivo principal del software creado es generar automáticamente 
un sistema de agentes con seguridad mutua estática a partir de 
un conjunto de agentes sin seguridad. 

Los ficheros de entrada que corresponde a los agentes sin 
seguridad deben cumplir ciertas restricciones (precondiciones) 
entre las que podemos comentar: 


= deben ser archivos precompilados java .class 
= deben representar a una clase que extienda de 
jade.core.A gent. 
= no pueden contener clases internas anónimas. 
De igual forma existen una serie de condiciones de salida 
que debemos tener muy en cuenta: 
= Cada uno de los nuevos agentes seguros tendrá asignado 


un agente protector, este agente protector no puede ser 
modificado en tiempo de ejecución. 


= el comportamiento del nuevo sistema de agentes con la 
seguridad incorporada será igual al del sistema original. 


La arquitectura general del sistema sigue el patrón Modelo- 
Vista-Controlador. Pero, ya que la vista es una simple interfaz 
gráfica de usuario para facilitar el uso de la herramienta, sólo 
vamos a mostrarla en la Figura 6 y nos centraremos en el 
modelo de datos y en sus fases de funcionamiento. 


Archivo Acciones Ayuda 


[E Agentes 
Y EA 

- [] Comportamiento 
[y Método: <init> 
[O Método: setup 
[y Método: escribir 
[) Campo: b 
[3 Campo: contador 
+ ab 


Información del agente B 
- Número total de métodos: 2 
- Número total de campos: 1 
- Número de métodos que se pueden proteger: 2 
- Número de campos que se pueden proteger: 0 
- Número de instrucciones: 2 
- Agente protector: No asignado 
- Agente protegido: No asignado 
- Nombre del agente seguro: SecureB 
- Porcentaje de seguridad: 0 


No se ha podido proteger el campo b 
Figura 6. Interfaz gráfica de usuario. 


Podemos dividir el funcionamiento de la herramienta en tres 
fases bien diferenciadas: carga de agentes originales, configu- 
ración de seguridad y creación de agentes con seguridad. Para 
cada una de estas fases se han implementado una serie de 
clases que se encargan de su correcto funcionamiento. 

Creemos que es mejor ilustrar todo el proceso con un 
ejemplo práctico, en el podremos observar con facilidad cada 
una de las etapas. 

La clase de la Figura 7 contiene el código de un agente 
JADE sin seguridad, como podemos observar hereda de la 
clase Agent y su código de ejecución está contenido en el 
método setup(). 


public class Ejemplo extends Agent( 


// Campos 


protected void setup() f 


// Instrucción que no se protegerá 
System.out.println("No protegida"); 


// Instrucción que si se protegerá 
System.out.println("Protegida"); 


Figura 7. Código de ejemplo. 


Puesto que es necesario que cada agente tenga un agente 
protector, el mínimo número de agentes para que el sistema 
tenga sentido es dos. Supongamos entonces que en este ejem- 
plo también contamos con un agente vacío (sin instrucciones 
ni datos), que hará la labor de agente protector. 
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A continuación vamos a explicar cada una de las fases por 
separado y nos centráremos en el ejemplo dado. 


IV-A. Fase I: Carga 


Esta es la primera fase en el proceso de generación de los 
agentes seguros. Su cometido es el de cargar los ficheros 
de clase y analizar todo su contenido. Para ello debemos 
seleccionar los agentes sin seguridad e identificar y analizar 
todos sus elementos, es decir, métodos, campos, instrucciones, 
clases internas, etc. 

En esta etapa de análisis de los ficheros .class utilizamos 
el componente estático de las librerías de BCEL. Como ya 
hemos comentado con anterioridad, esta parte de la API nos 
permite cargar un archivo .class y generar automáticamente 
la estructura de un fichero de clase [6]. Por cada uno de 
los elementos que conformar el fichero de clase (métodos, 
campos, clases internas, instrucciones, etc) se crea un objeto 
que lo modela y nos permite trabajar con él. 

Todos los elementos generados por este componente de 
BCEL son de solo lectura. Pero necesitamos guardar infor- 
mación de cada uno de estos elementos. Para ello hemos 
creado clases que heredan directamente de las clases que nos 
ofrece BCEL. En estas nuevas clases introducimos toda la 
información que utilizaremos en los procesos posteriores. 

Dentro de este proceso de análisis vamos a destacar y aclarar 
el caso de las instrucciones, ya que este es más complejo que 
los demás elementos. Como podemos observar en la Figura 5, 
dentro de los ficheros de clases hay una sección dedicada a 
los métodos de la clase. Entre otros elementos, dentro de estos 
métodos nos encontramos instrucciones bytecode. 

Estas instrucciones suelen carecer de sentido si se ejecutan 
por separado, es decir, que dependen de la antecesora y/o la 
sucesora. En la Figura 8 podemos observar la correspondencia 
entre una instrucción en java y el conjunto de instrucciones en 
bytecode. Por ello tomamos la decisión de agruparlas en con- 
juntos que correspondiesen a una instrucción java terminada 
en 3. 


System.out.printin( “Ejemplo”); 


GETSTATIC java/lang/System.out : Ljava/io/PrintStream; 
LDC "Ejemplo" 
INVOKEVIRTUAL java/io/PrintStream.printIn(Ljava/lang/String;)V 


Figura 8. Correspondencia. 


Una vez que estén cargados todos los agentes en el sistema 
pasamos a la fase de configuración, donde vamos a indicar el 
grado de seguridad y los enlaces de protección. 


IV-B. Fase H: Configuración 


La segunda fase del proceso es la más simple de las tres 
y la que ha resultado más fácil de implementar. Se trata de 
especificar los parámetros de seguridad con los que se crearán 
los nuevos agentes seguros. 


Existen dos elementos susceptibles a ser protegidos en un 
agente JADE: 


= instrucciones 
= datos (Campos de la clase) 


La información necesaria para determinar el grado de se- 
guridad será el porcentaje de instrucciones y los datos que 
queremos proteger. Toda esta información se modela con una 
clase llamada SecureAgentConfiguration. Se han implementa- 
do dos maneras de indicar los parámetros de seguridad. 

Con el primer método es necesario especificar por cada uno 
de los agentes cargados (en la primera fase) en el sistema 
los parámetros de seguridad. Esto implica seleccionar uno a 
uno los agentes e introducir el porcentaje de instrucciones y 
seleccionar los campos que queremos proteger. 

Este método puede ser poco fluido dependiendo del número 
de agentes cargados y el número de pruebas que deseemos 
realizar. Por ello, hemos implementado una opción que permite 
aplicar una plantilla de seguridad a todos los agentes cargados 
a través de un archivo XML. Existen tres plantillas básicas y 
la posibilidad de cargar la plantilla personal desde un archivo. 
En la Figura 9 podemos ver un ejemplo del formato de un 
fichero de configuración. En él podemos observar el porcentaje 
de instrucciones y de datos, 50 en este caso, que deseamos 
proteger. 


<?xml version="1.0" encoding="windows-1250"?> 


<configuracion> 


<instrucciones> 50 </instrucciones> 
<datos> 50 </datos> 
</configuracion> 


Figura 9. Formato del fichero XML. 


Es importante tener en cuenta que existen casos en los 
que estos porcentajes no se pueden cumplir con exactitud. En 
ocasiones no es viable proteger una instrucción o un dato, por 
ejemplo, los datos estáticos o las instrucciones de salto. 

Antes de pasar a la siguiente etapa y para concluir con la 
configuración debemos seleccionar cómo van a ser los enlaces 
de protección, es decir, indicar cómo van a protegerse los 
agentes entre ellos. No es necesario realizar esta acción man- 
ualmente mano ya que existe una opción para automatizarla 
en la aplicación gráfica. En nuestro caso, al existir únicamente 
dos agentes, se protegerán el uno al otro. 


IV-C. Fase II: Creación de los agentes seguros 


Por último, tenemos la fase de creación de los agentes se- 
guros. Gracias a los pasos anteriores en esta fase ya contamos 
con toda la información necesaria para la creación. 

Por cada uno de los agentes originales debemos crear al 
menos dos nuevas clases, una corresponderá al nuevo agente 
seguro que contendrá su código (datos e instrucciones) público 
y la otra el código privado. Además de estas clases se crearán 
tantas como clases internas contenga el agente original. 

Para crear estas nuevas clases precompiladas hemos utiliza- 
do el componente dinámico de BCEL. Con esta parte de la 
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API de BCEL creamos el esqueleto de los ficheros de clase 
y dependiendo de los parámetros de seguridad que se hayan 
establecido en la fase anterior introducimos él código original 
en una clase u otra. 

En la Figura 10 podemos observar el contenido de la parte 
publica del nuevo agente seguro basado en el ejemplo de la 
Figura 7. Se ha modificado la clase de la siguiente manera: 


public class SecEj extends SecureAgent( 


protected void setup() £ 
// Inicialización 


// Instrucción no protegida 
System.out.println("No protegida"); 


// Llamada al código remoto 
ACLMessage msg = new ACLMessage(...); 
msg.setContent("execute-my-..."); 
myArgs = argument; 
msg.addReceiver(this.protectedBy); 
send (msg); 


Figura 10. Agente seguro. 


= La nueva clase hereda de SecureAgent. 

= Se añade una sección de inicialización en el método setup 
donde se indica el agente protector y el protegido. 

= Se añade el código no protegido. 

= Se añaden solicitudes de ejecución de código remoto. 
Por cada sección de código que se haya protegido será 
necesario añadir las instrucciones para configurar los 
argumentos, realizar la llamada, esperar y recoger los 
resultados si los hubiera. 


Para el código protegido se crea otra clase que implementa 
la interfaz PrivateCode. En esta nueva clase debemos intro- 
ducir: 

= Los campos protegidos (ninguno en nuestro caso). 

= El método execute() que contendrá el código protegido 

dividido por secciones. La información para saber qué 
sección se debe ejecutar estará contenida en los argu- 
mentos del método. En nuestro caso y ya que el código 
a proteger cuenta con una única sección, esta estará 
directamente en el método execute() como muestra la 
Figura 11. 


V. CONCLUSIONES 


A lo largo de este artículo hemos presentado una 
metodología que, mediante el uso de ciertas herramientas de 
apoyo, nos permiten la protección automática de sistemas 
multiagentes. Todo lo presentado y a pesar de que todas 
las herramientas de apoyo son totalmente funcionales, es 
un trabajo académico. Por ello no se contemplan algunos 
características de los sistemas multiagentes como puede ser 
el dinamismo de los agentes. El siguiente paso es lógico y 
consistiría en el estudio de una metodología paralela aplicable 


public class Priv implements PrivateCodef 


// Campos protegidos 


public Object exucute(Object 0)f 


// Instrucción que si se protegerá 
System.out.println("Protegida”); 
return null; 


Figura 11. Codigo privado/protegido. 


a sistemas reales dinámicos. El estudio de esta metodología y 
su despliegue está en etapas avanzadas y sus resultados serán 
presentados en próximos trabajos. 
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Abstract—Actualmente la red eduroam está formada por una 
jerarquía de servidores RADIUS que permite la movilidad de 
los usuarios a través de las organizaciones pertenecientes a esta 
federación. Este trabajo describe cómo esta jerarquía puede ser 
mejorada mediante el uso de propuestas como RadSec y DAMe, 
para ofrecer mayor seguridad en la conexión y en el acceso 
a servicios. Este trabajo muestra una integración de ambas 
propuestas sobre eduroam y un análisis de rendimiento para 
comprobar su viabilidad. 

Index Terms—RadSec, DAMe, eduroam, federación. 


I. INTRODUCCIÓN 


Bajo el marco de TERENA se ha desplegado una de las 
mayores redes para roaming a nivel mundial, eduroam [1]. 
Esta red, orientada a instituciones relacionadas con la inves- 
tigación y la educación, permite la movilidad de usuarios 
a través de más de 40 países a lo largo de 3 continentes, 
incluyendo China, Australia, Canadá y próximamente EEUU. 

Para conseguir esta cobertura, eduroam hace uso de una 
jerarquía distribuida de servidores RADIUS a lo largo de cada 
zona geográfica, país e institución. De este modo, por ejemplo, 
cuando un usuario de la Universidad de Stuttgart realiza una 
solicitud de acceso a la red eduroam, durante su estancia en 
la Universidad de Calgary, en realidad lo que ocurre es que 
está solicitando acceso al servidor RADIUS de la universidad 
visitada. Este servidor redirige la solicitud al nivel superior 
de la jerarquía, y así sucesivamente, hasta que se alcanza el 
servidor RADIUS de la universidad local del usuario. En el 
caso de conexiones intercontinentales pueden requerirse hasta 
6 servidores intermedios para una autenticación del usuario. 
Otro de los problemas conocidos de este tipo de jerarquías es 
que la comunicación entre servidores se basa en conexiones 
UDP, protegidas a través de secretos compartidos. 

Para ofrecer mayor seguridad en las comunicaciones y 
mayor control sobre el proceso de autenticación del usuario se 
han definido varias propuestas. Por un lado, RadSec [2] pro- 
pone la extensión de RADIUS para el soporte de conexiones 
TCP/TLS; además, ofrece mecanismos de descubrimiento de 
la organización local del usuario, lo que permite evitar recorrer 
toda la jerarquía. Por otro lado, el proyecto DAMe [3] define 
cómo puede extenderse la jerarquía de eduroam para permitir 
servicios de Single Sign On (SSO) y control de acceso 
avanzado basado en atributos del usuario. 

Este trabajo presenta cómo ambas soluciones pueden coop- 
erar para ofrecer de un modo homogéneo todos los servicios 


de seguridad ofrecidos por ambas propuestas. Además, se 
presenta un análisis de rendimiento que permite comparar 
cómo el uso de canales TLS y mecanismos de descubrimiento 
pueden afectar al rendimiento de eduroam. 

Para describir esta integración, este trabajo está estructurado 
del siguiente modo. La Sección II describe la propuesta de 
DAMe, mientras que la Sección III hace una breve intro- 
ducción de RadSec. La Sección IV describe la integración de 
ambas tecnologías, indicando los componentes y mecanismos 
de descubrimiento. La Sección V presenta el análisis de 
rendimiento y la Sección VI describe brevemente el trabajo 
relacionado. Finalmente, la Sección VII presenta algunas con- 
clusiones y vías futuras. 


ll. DAME 


La arquitectura general de DAMe se puede ver en la 
Figura 1, donde se muestra que eduroam es la iniciativa central 
de este proyecto. La principal idea que se pretende conseguir 
con DAMe es desplegar sobre eduroam el intercambio de 
credenciales de autorización y ofrecer mecanismos de SSO, 
ya desde el acceso a la red. Con DAMe, cualquier usuario 
será autenticado inicialmente usando eduroam, obteniendo un 
token SSO (eduToken) que será utilizado posteriormente para 
acceder a otros recursos de la federación. 


Organización Visitada Organización Local 


RADIUS 


Attribute 
Release 
Policy 


Resource 
Access 
Policy 


Fig. 1. Arquitectura general de DAMe 


Respecto al proceso de autorización, esta arquitectura hace 
uso de eduGAIN [4] para ofrecer gestión de credenciales a 
nivel de federación sobre eduroam. De este modo, permite 
utilizar el sistema como back-end de control de acceso a la 
federación, mientras que cada organización de forma local 
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Fig. 2. Proceso de autenticación en DAMe haciendo uso de RadSec 


puede hacer uso de sus propios métodos de autenticación y au- 
torización. Para hacer uso de eduGAIN se deben desplegar los 
Bridging Elements (BE) correspondientes para la traducción de 
mensajes de autorización, autenticación y petición de atributos. 

En el escenario de la Figura 1 mostramos dos organiza- 
ciones. Una es la organización local del usuario, que aloja 
su Proveedor de Identidad (14P); por lo tanto, define como 
mínimo dos entidades, una autoridad de autenticación y una 
autoridad de atributos a la que solicitar información sobre 
dicho usuario. Además, es necesaria la existencia de un 
servidor RADIUS [5] conectado a eduroam para la fase de 
autenticación del usuario. 

En la organización destino aparecen tanto un servidor 
RADIUS conectado a eduroam, igual que en la organización 
local, un BE de eduGAIN que se encargará de traducir los 
mensajes recibidos a formato interno, y una entidad llamada 
Policy Decision Point (PDP) que se encarga de tomar la 
decisión de autorización en base a los atributos recibidos de 
la organización local. 


A. Autenticación de red 


En DAMe esta fase se basa en eduroam para poder au- 
tenticar al usuario a nivel de red, utilizando para ello la 
jerarquía de servidores RADIUS ya establecida. La extensión 
que se añade sobre este proceso consiste en que el servidor 
de autenticación de la organización local pueda solicitar a su 
BE un token (eduToken), que recibirá el usuario, con el que 
podrá acceder a otros servicios mediante SSO, 

Para evitar un posible robo del token por un usuario 


malintencionado, se debe proteger tanto el envío como el 
almacenamiento en el dispositivo del usuario. 


B. Distribución del token SSO de autenticación 


Para establecer un canal seguro entre el usuario y el servidor 
de autenticación, para el envío del token, podemos hacer uso 
de métodos EAP, como por ejemplo TTLS [6] o PEAP [7]. 
El token se almacena en el dispositivo del usuario de forma 
segura, para que luego pueda ser utilizado por los servicios a 
nivel de aplicación. 


C. Fase de autorización 


Una vez el usuario ha obtenido el token de autenticación, la 
organización visitada debe conocer las capacidades del usuario 
para decidir a qué servicios puede acceder, que características 
tendrá su conexión, etc. 

Para ello se establece una segunda fase en la que se realiza 
una consulta de los atributos del usuario, obtenidos desde su 
organización local a través de eduGAIN, que serán enviados 
al PDP para tomar la decisión de autorizar o no al usuario en 
base a esos atributos. 

DAMe se basa en el uso de tecnologías estándar, como 
SAML [8] o XACML [9]. Una descripción más detallada de 
este proceso puede encontrarse en [10]. 


TIT. RADSEC 


RadSec [2] ofrece una solución para implementar RADIUS 
haciendo uso de conexiones TCP/TLS, ayudando a que las 
transferencias de información de autenticación y autorización 
sean más eficientes y seguras. 
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En eduroam se hace uso de una jerarquía RADIUS tradi- 
cional, descrita anteriormente, donde todos los mensajes de 
autenticación y autorización recorren la jerarquía desde el 
servidor RADIUS remoto al local. Todo este intercambio, que 
se hace mediante UDP y usando un cifrado basado en secretos 
compartidos, se pretende cambiar, a nivel organizativo, por 
una conexión directa entre ambos servidores RADIUS y una 
arquitectura de clave pública para su seguridad. 

La principal idea de RadSec, además de establecer seguridad 
y eficiencia en la comunicación, es evitar que se deba hacer 
uso de toda la jerarquía de eduroam para la comunicación entre 
la organización local y visitada (como queda representado en 
la Figura 2). Para ello, se establece un canal directo entre 
los servidores RadSec remoto y local, estableciendo todo el 
intercambio de autorización y autenticación a través de dicho 
canal. 

Para que esta conexión pueda llevarse a cabo mediante 
TCP/TES deben existir una serie de elementos indispensables 
entre ambos servidores RadSec: 

. Certificado de clave pública para el servidor que soporta 

RadSec y su correspondiente clave privada. 

+. Autoridad de certificación (CA) emisora. 

+ Es necesario un modelo de confianza entre ambas or- 
ganizaciones, por ejemplo mediante una jerarquía de 
certificación común o a través de confianza mutua. 

+ Servicios de validación y descubrimiento. 

Finalmente, hay que tener en cuenta las características de 
autodescubrimiento que se plantean en RadSec, ya que la 
configuración estática de los servidores conocidos plantea un 
serio problema de escalabilidad [11]. Se han propuesto varias 
alternativas basadas en DNS [12], DNSSec [13] o publicación 
de metadatos, que serán descritas en la siguiente sección. Ac- 
tualmente la solución más utilizada es FreeRADIUS [14], que 
no tiene aún soporte para RadSec, por lo que será necesario 
hacer uso de entidades proxy, como radsecproxy [16], para 
desplegar esta solución. 


IV. ARQUITECTURA Y DESPLIEGUE 


Entre las distintas posibilidades de integración disponibles 
nos encontramos con Radiator [15], un software stand-alone 
de RADIUS que lleva integrado RadSec de forma nativa. Otra 
opción, por la que finalmente hemos optado, es la instalación 
de servidores radsecproxy que actúen como proxys entre los 
servidores FreeRADIUS. 

La arquitectura propuesta con RadSec quedaría como se 
puede ver en la Figura 2, donde los principales elementos de 
la arquitectura son: 

. Supplicant: Software instalado en el dispositivo del 
usuario para conectarse a la red. También debe permitir la 
creación de un canal seguro entre el usuario y el servidor 
RADIUS de su organización local. 

+. NAP: Punto de acceso que provee al usuario de acceso 
a la red. 

. RADIUS Remoto: Responsable de redirigir las peti- 
ciones de autenticación del usuario hacia el servidor 
RadSec de su organización. 


. RadSec Remoto: Responsable de descubrir el servicio 
RadSec de la organización local del usuario y de enviar 
las peticiones recibidas del servidor RADIUS hacia éste. 

. Servidor DNS/MDS: Para el descubrimiento de la or- 
ganización local, será necesario definir el mecanismo 
a utilizar, DNS o MDS. Los requerimientos de estos 
servicios se describirán más adelante. 

+. RadSec Local: Servidor RadSec de la organización local 
que recibe las peticiones de conexión del usuario desde 
el servidor RadSec Remoto. Estas peticiones serán reen- 
viadas al servidor RADIUS Local para que realice la 
autenticación del usuario. 

. RADIUS Local: En base a la petición de autenticación 
recibida realiza la autenticación correspondiente y solicita 
al IdP, a través del BE Local, una sentencia SAML 
(eduToken) que será enviado al usuario y con el que podrá 
comenzar futuras sesiones de SSO. 

+. BE Local: Encargado de traducir la solicitud del servidor 
RADIUS Local a la tecnología utilizada por el IdP. Con 
la información recibida de éste, el BE Local creará el 
eduToken que le será enviado al usuario, en función de 
la información recibida del IdP. 

+. IdP: Entidad que maneja los atributos y las identidades 
de los usuarios, la cual recibe consultas de autenticación 
desde el BE Local. También recibe peticiones de atrib- 
utos de los usuarios durante la fase de autorización. El 
IdP puede estar basado en diferentes tecnologías como 
Shibboleth [17], PAPI [18], etc. 


La interacción entre las entidades añadidas para la inte- 
gración de RadSec en DAMe queda reflejada en la Figura 2. 
A continuación, mostramos paso a paso el proceso completo 
que seguiría una interacción común de autenticación en DAMe 
con RadSec. 


A. Autenticación 


Inicialmente, el Supplicant del usuario hace una petición 
de acceso a la red al NAP y, como en un esquema eduroam 
común, éste envía un mensaje Access-Request al servidor 
RADIUS de la organización visitada. 

En este punto, el servidor RADIUS Remoto, que tendrá con- 
figurado el servidor RadSec de su organización como proxy, 
le reenviará el mensaje mediante un mensaje RADIUS UDP 
común y será el proxy RadSec el encargado de transmitirlo a 
la organización local a través de un canal seguro entre ambas 
organizaciones. 

El servidor RadSec Remoto procede con el descubrimiento 
del servidor RadSec de la organización local. El proceso de de- 
scubrimiento dinámico de entidades RadSec queda explicado 
en el siguiente subapartado. Una vez descubierto el servidor 
RadSec de la organización local, se procede a crear un canal 
seguro entre los dos servidores haciendo uso de TLS. A partir 
de este momento, todos los mensajes se intercambiarán de 
manera segura. 

Una vez que el mensaje de autenticación llega al servidor 
RadSec Local, éste se encontrará configurado para retransmi- 
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tirlo al servidor RADIUS de su organización, que procederá 
con el proceso de autenticación. 

Para dicha autenticación se sigue el funcionamiento común 
de DAMe, realizando una petición del token de autenticación 
(edutToken) al IdP local, a través del BE Local. 

Una vez tomada la decisión de autenticación, se procede a 
enviar el mensaje Access-Accept desde la organización local 
a la visitada. En este caso, el servidor RADIUS Local, que 
tendrá configurado el servidor RadSec de su organización 
como proxy, le enviará el mensaje para que sea reenviado 
a través del canal seguro TLS. Una vez que el servidor 
RadSec Remoto recibe dicho mensaje, lo reenvía a su servidor 
RADIUS que será el encargado de hacerlo llegar al punto de 
acceso desde donde el usuario está tratando conectarse, y que 
le dará el permiso para poder acceder a la red. 


B. Transmisión del token y fase de autorización 


Una vez que el servidor RADIUS Local obtiene el token 
SSO, lo envía a través del canal seguro y éste se almacena en el 
dispositivo del usuario, tal y como se comentó anteriormente. 

Respecto a la fase de autorización, no se ve afectada por la 
integración de RadSec, por lo que se sigue el proceso normal 
que se realiza en DAMe. 


eduroam 
RADIUS 


Pos 


Fig. 3. 


Descubrimiento dinámico en RadSec 


C. Autodescubrimiento 


Una vez definida la integración de los servidores RadSec 
en DAMe, se debe plantear una solución al problema del 
descubrimiento de los puntos de autenticación del resto de 
organizaciones. 

En nuestro caso estudiamos dos posibles vías: haciendo uso 
del servicio de descubrimiento de nombres DNS; y mediante 
el uso de un servicio común de metadatos (MDS) siguiendo 
la propuesta de eduGAIN. 

1) Autodescubrimiento usando DNS: Para llevar a cabo este 
método, la organización local debe anunciar, mediante una en- 
trada SRV en su servidor DNS, el servidor RadSec que estará 
esperando conexiones entrantes de otras organizaciones. El 
servidor RadSec Remoto hará una consulta DNS preguntando 
por el servicio _radsec._tcp dentro del dominio local, como 
se establece en [2]. 

Una vez conocido el servidor RadSec de la otra orga- 
nización, se procede al establecimiento del canal seguro, 


haciendo uso de los certificados que tanto el servidor de la 
organización visitada como el de la local tienen. El uso de 
DNSSec en RadSec también se ha propuesto, aunque queda 
fuera del ámbito de este trabajo y se planteará como trabajo 
futuro. 

En la Figura 3 puede verse un esquema de la interacción 
del DNS en el esquema de DAMe. 

2) Autodescubrimiento usando eduGAÍN MDS: En este 
otro caso se ha usado la estructura de metadatos ofrecida por 
eduGAIN para hacer el anuncio de servicios. 
<md:EntityDescriptor ID="...” entityID="...”> 

<md:IDPSSODescriptor ID="USTUTT-RADSEC”> 

<md:SingleSignOnService Location="radsec(*)://ksat.rus.uni-stuttgart.de:2083”/> 

</md:IDPSSODescriptor> 

<md:Organization > 

<md:Extensions > 

<egmd:HL Pattern egmd:MatchingAlgo="urn:..:metadata:exact”> 
uni-stuttgart.de 
</egmd:HL Pattern> 
</md:Extensions > 


</md:Organization> 
</md:EntityDescriptor> 


Listing 1. Ejemplo de fichero MDS 


Será la organización local la que haga uso de un reposito- 
rio de metadatos para anunciar su servidor RadSec, y será 
el cliente (en nuestro caso el servidor RadSec Remoto) el 
encargado de preguntar a dicho repositorio por el servidor que 
desea localizar. Esta solución tiene algunas consideraciones de 
seguridad a ser tomadas en cuenta, como por ejemplo: 


+ El servidor remoto debe asegurarse que pregunta al MDS 
correcto, haciendo uso de los certificados correspondi- 
entes. 

+. El MDS debe validar la información que anuncia. 


En el Listado 1 mostramos un ejemplo de la información 
almacenada en el MDS, que servirá para el descubrimiento 
del servicio de RadSec en la organización local. 

En la Figura 3 se ve también la integración del servidor 
MDS para la obtención de la información necesaria por parte 
de la organización visitada. 


V. MEDIDAS DE RENDIMIENTO 


En esta sección detallamos la viabilidad a la hora de 
introducir RadSec en la arquitectura actual de DAMe. 


Elemento Hardware Software 
Organización Visitada (Universidad de Murcia) 
Pentium M 1.60 GHz 


Suppplicant S12MB RAM WPASupplicant 0.6.3 
NAP Linksys WRT54G - 
RADIUS AMD Opteron 246 FreeRADIUS 1.1.3 
RadSec 1GB RAM radsecproxy 1.3.1 


Organización Local (Universidad de Stuttgart) 


DNS BIND 9.4.2-P2.1 
MDS Pentium Dual 2GHz Apache 2.2/mod_ssl 
RadSec 2GB RAM radsecproxy 1.3.1 
RADIUS FreeRADIUS 2.0.2 
BE Local Pentium IV 3GHz Tomcat 5.5.27 
TP 1GB RAM Shibboleth 1.3 
OpenLDAP 2.3.28 
TABLE I 


ELEMENTOS HARDWARE Y SOFTWARE DEL TESTBED 
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Autenticación estándar | Autenticación estándar Autenticación extendida 
(eduroam) (eduroam + RadSec) (eduroam + RadSec + eduToken) 
2082 / 2389 
1498 / 753 1319 DNS/MDS | Autenticación Shibboleth | Obtener eduToken 
81 / 388 54 628 
TABLE HU 


MEDIANA DE LOS TIEMPOS OBTENIDOS PARA LAS MEDIDAS DE RENDIMIENTO (MS) 


Para ello, se ha utilizado la infraestructura desplegada 
en DAMe, incluyendo los servicios que tanto eduroam y 
eduGAIN proporcionan para, respectivamente, autenticar y 
autorizar a los usuarios de la federación. Como hemos co- 
mentado anteriormente, esta arquitectura se ha extendido 
añadiendo únicamente dos servidores RadSec (uno por orga- 
nización). 

Las pruebas realizadas se han llevado a cabo entre la 
Universidad de Murcia (organización visitada donde el usuario 
quiere conectarse a la red) y la Universidad de Stuttgart 
(organización local a la que el usuario pertenece). 

En la Tabla I mostramos los detalles hardware y software de 
los elementos utilizados para desplegar el escenario explicado 
anteriormente (ver Figura 2). El sistema operativo utilizado 
en todos los componentes es una Ubuntu Kernel 2.6.24, a 
excepción del BE Local/IdP que es un Windows 2003 SP2. 

Todas las muestras de tiempo obtenidas en esta sección, 
medidas en milisegundos, se han realizado ejecutando 105 
veces la prueba correspondiente de forma secuencial. 

Las pruebas que se han realizado, como se puede ver en la 
Tabla II (una prueba por columna), son las siguientes: 


e. Autenticación estándar/básica en eduroam. 

e Autenticación estándar en eduroam a través de los servi- 
dores RadSec. 

+. Autenticación extendida en eduroam, a través de los 
servidores RadSec, incluyendo la generación del token 
SSO (eduToken) por parte del IdP de Stuttgart. 


En este último caso hemos realizado dos pruebas difer- 
entes, según el método de autodescubrimiento utilizado por 
el RadSec Remoto para localizar el servidor RadSec Local de 
la Universidad de Stuttgart: mediante DNS o MDS. Ambos 
servicios, como podemos ver en la Tabla l, han sido instalados 
en la organización local (Universidad de Stuttgart). 

En la Tabla Il se muestran las medianas de los tiempos 
obtenidos para cada una de las pruebas anteriores. En la 
primera columna se visualizan los tiempos para una auten- 
ticación estándar con eduroam. En este caso, hemos realizado 
dos pruebas: 


+ Estableciendo un canal PEAP con Stuttgart usando toda 
la jerarquía RADIUS de eduroam, compuesta por 5 
servidores en total, obteniendo un tiempo de 1498ms. 
Viendo estos tiempos podemos ver cómo la utilización de 
RadSec (segunda columna) es ligeramente mejor, 1319ms 
frente a 1498ms, ya que se evita tener que recorrer toda 
la jerarquía RADIUS de eduroam. 

+ Estableciendo el canal PEAP directamente entre los dos 
servidores RADIUS de ambas universidades, obteniendo 


un tiempo de 753ms. Esta prueba se ha realizado para 
comprobar qué diferencia de tiempo hay entre utilizar 
RadSec o no, sin tener en cuenta la jerarquía RADIUS 
de eduroam, ya que RadSec no la utiliza. En este caso, 
podemos ver que la introducción de RadSec supone un 
incremento de 753ms a 1319ms; es decir, un 75% de 
sobrecarga. 


Como primera conclusión de estos tiempos podemos afirmar 
que, aunque la introducción de RadSec supone un incremento 
considerable, los tiempos en DAMe son incluso ligeramente 
mejores (sobre el 13%, de 1498ms a 1319ms). Esta mejoría 
se debe a que ya no es necesario tener que recorrer toda la 
jerarquía RADIUS establecida en eduroam. 

La última columna de la Tabla II muestra el tiempo obtenido 
en la autenticación eduroam, con soporte RadSec, incluyendo 
la generación del eduToken, como se realiza en DAMe. En 
esta prueba, los tiempos se dividen dependiendo del tipo de 
autodescubrimiento utilizado. Haciendo uso de un servicio 
DNS obtenemos un tiempo total de 2082ms, mientras que la 
utilización de MDS supone un tiempo de 2389ms. Podemos 
comprobar que ambos tiempos son asumibles por parte del 
usuario, aunque la diferencia entre ambos métodos de autode- 
scubrimiento es un factor bastante significativo (de 8lms para 
el DNS a 388ms para el caso del MDS). 


2500 2389 
2082 
2000 
2 dba A E AuthN Shibboleth 
Bl 1500 E Obtener eduToken 
> E Descubrimiento (DNS/MDS) 
Z 1000 E eduroam + RadSec 
e E eduroam 
500 
0 
estandar DNS MDS 


AuthN con RadSec 


Fig. 4. Tiempos de autenticación con/sin RadSec 


La Figura 4 muestra gráficamente los mismos tiempos que 
se incluyen en la Tabla II, para así poder compararlos de forma 
más intuitiva. En este caso podemos distinguir claramente el 
incremento que supone la utilización del autodescubrimiento 
por DNS y MDS. 

Finalmente, todos los tiempos obtenidos utilizando el au- 
todescubrimiento mediante DNS se ilustran en la Figura 5. 
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Fig. 5. Percentil de la autenticación con RadSec (DNS) 


Todos los tiempos que hemos presentado en esta sección 
están relacionados con la fase de autenticación que se realiza a 
través de eduroam. Para el proceso completo de autenticación 
y autorización, como se establece en DAMe, faltaría incluir 
a estos tiempos la última fase de autorización por red. Este 
tiempo, también sobre DAMe, ha sido calculado en [19], obte- 
niendo 531ms. Por tanto, si sumamos este tiempo al obtenido 
en esta sección para la fase de autenticación (2082ms, para el 
caso de DNS), tendríamos un tiempo total de 2613ms. Este 
tiempo sigue siendo asumible por el usuario final para obtener 
la conexión de red solicitada en la organización visitada. 


VI. TRABAJO RELACIONADO 


No existen trabajos realizados sobre esta temática que 
incluyan una integración completa de RadSec en una ar- 
quitectura definida junto con medidas de rendimiento. Este 
trabajo se basa principalmente en la documentación generada 
en GEANT [20][21], donde se presentan diferentes alternativas 
a la integración de RadSec en eduroam. 


VII. CONCLUSIONES Y TRABAJO FUTURO 


Este trabajo presenta una propuesta de integración de 
RadSec y DAMe sobre una red en producción como es 
eduroam, por lo que se ofrece una mejora significativa sobre 
los problemas de seguridad relacionados con RADIUS. Para 
comprobar la viabilidad de la propuesta se ha realizado un 
análisis del rendimiento sobre un escenario real, entre dos 
organizaciones conectadas a la federación. El análisis muestra 
que la integración de RadSec mejora los tiempos de comu- 
nicación sobre el uso tradicional de la jerarquía RADIUS, y 
que, además, la integración con DAMe supone unos tiempos 
asumibles por el usuario, teniendo en cuenta que además de 
mayor seguridad en las comunicaciones, podrá hacer uso de 
mecanismos avanzados de autorización y de SSO. 

Como trabajo futuro se plantea la integración del escenario 
con mecanismos NEA para el control de acceso basado en 
atributos del dispositivo del usuario, y la integración del 
proceso de intercambio de atributos con RadSec. 


AGRADECIMIENTOS 


Este trabajo ha sido parcialmente financiado por el proyecto 
MULTIGIGABIT EUROPEAN ACADEMIC NETWORK 
(FP7-INFRASTRUCTURES-2009-1), y el programa de exce- 
lencia para grupos de investigación de la Fundación Séneca 
(04552/GERM/06). 


REFERENCES 


[1] K. Wierenga et al. “Deliverable DJS.1.4: Inter-NREN Roaming Archi- 
tecture. Description and Development Items”. GN2 JRAS, GÉANT 2, 
Septiembre 2006. 

[2] S. Winter, M. McCauley, S. Veenas and K. Wierenga. “TLS encryption 

for RADIUS”. IETF Internet-Draft 06, Marzo 2010. 

[3] DAMe Project. Website: http://dame.inf.um.es 

[4] D.R. López, J. Macías, M. Molina, J. Rauschenbach, A. Solberg and M. 

Stanica. “Deliverable DJ.5.2.3,2: Best Practices Guide - AAI Cookbook 

- Second Edition”. GN2 JRA5, GÉANT?2, Marzo 2007. 

[5] C. Rigney, S. Willens, A. Rubens and W. Simpson. “Remote Authenti- 

cation Dial in User Service (RADIUS)”. RFC 2865, Junio 2000. 

[6] P. Funk and S. Blake-Wilson. “EAP Tunneled TLS Authentication Pro- 

tocol (EAP-TTELS)”. TIETF Internet-Draft 05, Julio 2004. 

[7] A. Palekar, D. Simon, J. Salowey, H. Zhou, G. Zorn and S. Josefsson. 

“Protected EAP protocol (PEAP) Version 2”. TIETF Internet-Draft 10, 

Octubre 2004. 

[8] E. Maler, P. Mishra and R. Mishra (Ed.). “Assertions and Protocol for 

the OASIS Security Assertion Markup Language (SAML) V1.1”. OASIS 

Standard, Septiembre 2003. 

[9] T. Moses (Ed.). “eXtensible Access Control Markup Language (XACML) 
Version 2.0”. OASIS Standard, Febrero 2005. 

[10] O. Cánovas, M. Sánchez, G. López, R. del Campo, S. Neinert, J. 
Rauschenbach and I. Thomson. “Deliverable DJ.5.3.2: Architecture for 
Unified SSO”. GN2 JRAS5, GEANT?2, Mayo 2008. 

[11] T. Lenggenhager et al. “Deliverable DJ5.4.1,2: Advanced Technologies 
Overview, Second Edition”. GN2 JRA5, GEANT?2, Febrero 2009. 

[12] S. Winter and M. McCauley. “NAl-based Dynamic Peer Discovery for 
RADIUS over TLS and DTLS”. IETF Internet-Draft 02, Marzo 2010. 

[13] DNS Extensions (dnsext), IETF Network Working Group. Website: 
http://datatracker.ietf.org/wg/dnsext/charter 

[14] The FreeRADIUS Project. Website: http://freeradius.org 

[15] Radiator Project. Website: http://www.open.com.au/radiator 

[16] radsecproxy. Website: http://software.uninett.no/radsecproxy 

[17] T. Scavo and S. Cantor. “Shibboleth Architecture: Technical Overview”. 
Internet2 Working Draft 02, Junio 2005. 

[18] D.R. López and R. Castro-Rojo. “Ubiquitous Internet Access Control: 
The PAPI System”. Proceedings of the 13th International Workshop on 
Database and Expert Systems Applications (DEXA), pp.441-445, 2002. 

[19] M. Sánchez, G. López, O. Cánovas, A.F. Gómez-Skarmeta. “Perfor- 
mance Analysis of a Cross-layer SSO Mechanism for a Roaming Infras- 
tructure”. Journal of Network and Computer Applications, 32(4):808-823, 
Febrero 2009. 

[20] S. Winter, T. Wolniewicz and I. Thomson. “Deliverable DJ3.1.1: RadSec 
Standardisation and Definition of eduroam Extensions”. GN3 JRA3, 
GEANT3, Noviembre 2009. 

[21] S. Winter, M. Milinovic and I. Thomson. “Deliverable DS5.4.1: Report 
on RadSec Integration”. GN2 SAS, GÉANT?, Julio 2008. 


264 


REDUCCIÓN DE LA REDUNDANCIA DE 
CIFRADO EN REDES BASADAS EN TCP/IP Y 
802.11 


Antonio Urbano Fullana!, Josep Lluís Ferrer Gomila? y Magdalena Payeras Capella? 


Universitat Illes Balears, 


Dept. Matemáticas e Informática, 
Ctra. Valldemossa, Km 7,5. 07120, Palma 


ó ] ; 1 
e-mail antonio.urbanoluib.es 


Jjlferrertuib. s? 


3 


Resumen—Los servicios tradicionales sobre redes cableadas 
pueden operar, en la actualidad, sobre redes inalámbricas. A 
los mecanismos de seguridad existentes en las capas del modelo 
TCP/IP, se añaden los mecanismos de seguridad de capa MAC 
y por tanto se generan duplicidades, e incluso multiplicidades, 
en el cifrado de determninados octetos. El conocimiento de los 
mecanismos de cifrado utilizados en las diferentes capas y en 
particular de los octetos cifrados por cada uno de ellas, puede 
ayudar a elimar esta redundancia de cifrado. En este artículo 
analizamos los servicios de seguridad en la arquitectura TCP/1P 
sobre redes TEEE 802.11, propoponemos una solución que 
elimina la redundancia en el cifrado y, finalmente, cuantificamos 
el número de octetos cifrados en función de la longitud de 
los datos realizando una comparativa entre los octetos que 
se cifrarían al aplicar la propuesta realizada y los cifrados 
actualmente. 


Keywords: Wireless Security, Security Protocols, WEP, IPSEC, 
802.11. 


I. INTRODUCCIÓN. 


En este artículo presentamos un escenario donde un usuario 
A desea acceder a un servidor S a través del protocolo HTTPS. 
El servidor pertenece a una empresa que permite el acceso a 
sus servidores a través de conexiones VPN (Virtual Private 
Network). El usuario A es un terminal inalámbrico que 
opera en una red 802.11 [1] y que implementa seguridad a 
nivel MAC. Los servicios de seguridad requeridos en nuestro 
escenario son confidencialidad de la información extremo a 
extremo, el establecimiento de un túnel IPSEC (IP Secure) 
para disponer de seguridad puerta a puerta en los paquetes a 
nivel IP y seguridad a nivel MAC en 802.11. Este terminal 
implementará SSL a nivel de tranporte, IPSEC a nivel IP y 
WEP a nivel MAC. La red 802.11 de nuestro escenario es 
una red en modo infraestructura gestionada por un punto de 
acceso (AP) que también implementa WEP a nivel MAC. 
Los servicios de seguridad incluyen cifrado de la información 
y, en este artículo, demostramos que determinados octetos 
son cifrados por los tres mecanismos indicados. Definimos 
la Profundidad de Cifrado (PC) como el número de veces 
que un campo de un protocolo de capa ha sido cifrado en su 
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descenso por la pila TCPAP [10] hasta la capa física. 


Este artículo se organiza como sigue. En la sección Il 
estudiamos el encapsulado de los protocolos de la pila TCP/IP 
y de los servicios de seguridad SSL, IPSEC y WEP. El análisis 
de los mecanismos de cifrado utilizados y de la redundancia de 
cifrado se realiza en la sección III. La solución presentada en 
la sección IV elimina la duplicidad de cifrado. En la sección 
V presentamos los resultados obtenidos al aplicar la solución 
presentada y cuantificamos la reducción del número de octetos 
cifrados. 


Ill. TCP/IP Y LOS SERVICIOS DE SEGURIDAD. 


TCP/1P constituye el estándar de comunicaciones entre 
dispositivos conectados a Internet. TCP/IP es una colección de 
protocolos estándar de la industria diseñada para intercomu- 
nicar grandes redes WAN (Wide Area Network). El escenario 
presentado en la sección 1 se implementa sobre la pila TCPAP 
y utiliza los protocolos de capa y mecanismos de seguridad 
que se indican en la tabla 1: 


Resumen de protocolos y mecanismos de seguridad en el escenario descrito ] 
Capa Protocolo Mecanismo Seguridad | 
APLICACION HTTP - | 
TRANSPORTE TCP SSL | 
RED IP IPSEC | 
ENLACE 802.11 WEP | 
FISICA 802.11 - | 


Tabla I 
RESUMEN PROTOCOLOS 


A continuación introducimos estos protocolos detallando las 
sobrecargas introducidas por cada uno y los octetos afectados 
por los mecanismos de cifrado de capa. 


IFA. HTTP 


El protocolo HTTP/1.1 (Hypertext Transfer Protocol) [9] 
es el protocolo utilizado por el servicio World Wide Web 
(WWW). HTTP está orientado a transacciones donde el 
cliente especifica en la información enviada al servidor que 
acción quiere ejecutar. Definimos L como la suma de las 
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longitudes de los datos y la cabecera del protocolo HTTP en 
octetos. 


IF-B. SSL 


SSL [2] proporciona integridad y confidencialidad a 
los datos de aplicación. Opera a nivel de transporte y su 
arquitectura, detallada en la figura 1, está formada por 4 
subprotocolos. SSL transmite los datos utilizando la clave y 
el algoritmo de cifrado negociados al inicio de la conexión 
SSL entre cliente y servidor. 


SSL Handshake Protocol Sor Change Cipher | SsT Atert Protocol HTTP 
Suite Protocol 


SSL Record Protocol 


TCP Protocol 


IP Protocol 


Figura 1. Arquitectura SSL. 


En la capa de transporte, SSL divide los datos de la capa 
de aplicación en bloques de longitud máxima 16384 octetos 
sobre los que genera un hash. El campo de datos y el hash 
son cifrados utilizando el algoritmo acordado en la fase 
de negociación. La cabecera del protocolo SSL tiene una 
longitud de 3 octetos. 


Con el objeto de proporcionar datos concretos, suponemos 
que el algoritmo hash utilizado es MD5, que genera un 
campo de resumen de 16 octetos y el algoritmo de cifrado 
negocidado es RC4-128. Con estos datos la longitud de datos 
de cifrado es de (L+16) y la información enviada al módulo 
TCP tiene una longitud de 5+L+16 = 21+L octetos (ver figura 
2). 


SSL Header 
(5 octetos) 


[HTTP Header and HTTP Body 
(L <16384 octetos) 


a) 


Cifrado SSL 
RC4 


SSL MAC 
(16 octetos) 


Figura 2. Estructura de datos de SSL Record Protocol 


IC. TCP 


TCP [5] es el protocolo de capa de transporte. Divide 
los datos de aplicación en función del tamaño máximo del 
segmento que se define por el parámetro MSS (Maximum 


Segment Size). La cabecera TCP, sin considerar opciones, 
introduce un overhead de 20 bytes (ver figura 3), para formar 
un segmento de 20+5+L+16 = 41+L octetos. Consideremos 
que L es menor que el tamaño máximo de segmento. 


0 78 15 16 2324 31 
Source Port Destination Port 
ACK number 
20 
Sequence number octetos 
Offset Reserv TCP Flags Window 
Checksum Urgent Pointer 
Figura 3. Cabecera TCP. 


El protocolo IP [4] opera en la capa de red y es el 
encargado de transportar los datos de un origen a un destino. 
El protocolo IPv4 introduce un overhead, debido a la 
cabecera (ver figura 4) de 20 octetos para formar un paquete 
de longitud 61+L octetos (ver figura 5). 


0 78 15 16 2324 31 
Version IHL Type Total Length 
Time to Live Protocol Header Checksum 
20 
Identification Flags Fragment Offset oEtelES 
Source Address 
Destination Address 
Figura 4. Cabecera IP versión 4 

Bi. IP Header 
B20 
Ba1 TCP Header 
Bao 
Bar SSL Header 
Bas 
Ba6 HTTP Header 

Buéss HTTP Body Cifrado SSL RC4 

Bar+L SSL MAC 

B62+L 

Figura 5. Formato paquete IP. 
II-DI. IPSEC: IPSEC [6] es el protocolo que ofrece 


servicios de seguridad en la capa de red de la pila TCP/AP. 
IPSEC está formado por un conjunto de protocolos que 
operan individual o colectivamente para ofrecer mecanismos 
de seguridad: 

1. IKE (Internet Key Exchange). 

2. AH (Authentication Header). 

3. ESP (Encapsulating Security Payload). 


IKE [3] es el protocolo usado para establecer las 
asociaciones de seguridad en IPSEC. AH [7] proporciona 
integridad y autenticación al protocolo IP así como protección 
frente a ataques de repetición. ESP [8] además de los servicios 
ofrecidos por AH, proporciona confidencialidad al protocolo 
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IP. 


IPSEC fue diseñado para ofrecer servicios de seguridad en 
dos modos de funcionamiento: 


1. Modo túnel. La seguridad se establece puerta a puerta. 
En este modo, todo el paquete IP incluyendo cabeceras 
y datos es cifrado y autenticado por lo que es necesario 
generar un nuevo paquete IP. Este modo es utilizado 
para comunicaciones red a red u ordenador a ordenador 
sobre Internet. 

2. Modo transporte. La seguridad se establece extremo a 
extremo. Son los dispositivos finales los que realizan 
todos los procesos asociados con la seguridad. En este 
modo sólo se cifra y autentica la carga útil del paquete. 
La cabecera IP no es modificada y la integridad de la 
información de las capas de transporte y aplicación se 
realiza mediante un hash de los datos. 


En nuestro escenario consideramos que IPSEC implementa 
ESP en modo túnel para ofrecer confidencialidad en la 
cabecera IP. Para analizar el overhead introducido, suponemos 
que el algoritmo de cifrado utilizado es 3DES y que el 
algoritmo de autenticación es HMAC-MD53-96 (genera 12 
octetos de información). IPSEC con el protocolo ESP en 
modo túnel y con los algoritmos indicados, añade un overhead 
de 52 octetos (8 octetos de cabecera ESP, 8 octetos de vector 
IV, 12 octetos de autenticación y 4 octetos del campo ESP 
trailer, más una nueva cabecera IP de 20 octetos) (ver figura 
6). La longitud total del nuevo paquete con seguridad IPSEC 
es de 52+61+L = 113+L octetos. 


NEW IP Header 


2 ESP Header 


B37 IP Header 


TCP Header 


Br77 SSL Header 


Cifrado 
IPSEC 3DES Bg2 HTTP Header 


Cifrado 


HTTP Body SS ROE 


SSL MAC 


ESP Trailer 


[0] 
fa 
a 
Pi 
Lon 
SS 


ESP Authentication 


Figura 6. Formato paquete IPSEC, ESP modo túnel. 


IFE. Nivel LLC 


El nivel LLC añade 8 octetos de cabecera que sumados a 
los octetos del paquete IP con IPSEC suman 121+L octetos. 


IF. 802.11 


El estándar 802.11 define las capas física y MAC, para 
comunicaciones en redes locales inalámbricas. El estándar 
ha evolucionado desde la versión 802.1la, que opera en la 


banda de 5Ghz a velocidades de hasta 54 Mbit/s, o la versión 
802.11b, que opera en la banda de 2,4Ghz a velocidades de 
hasta 11 Mbit/s, hasta la versión 802.11n que implementa la 
nueva tecnología MIMO a velocidades de hasta 600 Mbit/s. 
El overhead introducido por 802.11 en la comunicación 
entre una estación y el punto de acceso es de 28 octetos y 
corresponde a la cabecera MAC y al campo FCS final. La 
longitud total de la trama 802.11 es de 155+L octetos, siendo 
155+L menor que la longitud máxima de trama (2312 octetos). 


Il-FI. WEP: El estándard IEEE 802.11 [1] define 
WEP como mecanismo opcional de cifrado de capa MAC. 
WEP ofrece privacidad de datos a nivel MAC en una red 
inalámbrica y se basa en el algoritmo de cifrado RC4 y en 
sus variantes de clave de 40 bits (WEP-40), a la que se le 
añade un vector de inicialización (1V) de 24 bits para formar 
la clave RC4. Esto conforma el estándard WEP de 64 bits. La 
versión WEP de 128 bits utiliza una clave de RC4 de 104 bits 
(WEP-104) a la que se le añaden los 24 bits del vector IV. 
El overhead adicional a la cabecera 802.11 introducido por 
WEP es de 8 octetos que corresponden a los campos vector 
IV (4 octetos) y al campo ICV (4 octetos) correspondiente 
a la aplicación del CRC-32 del algoritmo WEP sobre los datos. 


TIT. ANÁLISIS DE LOS SERVICIOS DE SEGURIDAD 


En la sección anterior hemos analizado el encapsulado 
de los datos de aplicación hasta formar la trama 802.11 
incluyendo los servicios de seguridad de cada capa (SSL, 
IPSEC y WEP) y los protocolos HTTP, TCP e IP. A 
continuación analizamos el impacto del cifrado realizado por 
cada uno de estos mecanismos de seguridad de capa sobre la 
información entregada por la capa superior. 


El primer cifrado que se realiza es el que implementa SSL y 
se realiza sobre los campos de datos y hash del protocolo SSL 
Record con una longitud total de 16+L octetos (Ver figura 2). 
La PC (definida en la sección I) para estos campos es igual a 1. 


Las capas TCP e IP añaden sus respectivas cabeceras al 
segmento entregado por SSL. IPSEC recibe el paquete IP de 
longitud 61+L octetos y el protocolo de seguridad ESP cifra 
el paquete IP y el campo ESP Trailer. El paquete IP original 
contiene los datos introducidos por la capa de aplicación y 
que han sido cifrados por SSL, con una longitud de 16+L 
octetos y que vuelven a ser cifrados por IPSEC, modificando 
su profundidad de cifrado a 2. Los campos de cabecera IP 
(Q0 octetos), cabecera TCP (20 octetos), cabecera SSL (5 
octetos) y ESP Trailer (4 octetos) no han sido cifrados en 
capas superiores por lo que su PC será igual a 1 (ver figura 6). 


El paquete IP junto a la cabecera LLC forman los datos 
a nivel 802.11 con una longitud de 121+L octetos y sobre 
los que se aplica el cifrado WEP. Los campos cifrados por 
IPSEC aumentan su PC por lo que a nivel MAC tendremos 
que la cabecera IP (20 octetos), la cabecera TCP (20 octetos), 
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la cabecera SSL (5 octetos) y el campo ESP Trailer (4 
octetos) tienen ahora una PC igual a 2. Por otra parte el 
campo de datos de aplicación y el campo hash SSL (16+L 
octetos) vuelven a cifrarse por lo que su PC actual es igual 
a 3. En esta capa también se cifran los campos de cabecera 
LLC (8 octetos), la nueva cabecera IP del protocolo IPSEC 
(Q0 octetos), la cabecera ESP (16 octetos), el campo de 
autenticación del protocolo ESP, ESP AUTH (12 octetos) y 
el campo de CRC-32 de los datos ICV (4 octetos). Estos 
campos tienen una PC igual a 1. 


802.11 Header 


Boas IV 


B29 LLC Header 


B37 NEW IP Header 


57 ESP Header 


B73 IP Header 
Bg2 
Bg3 TCP Header 
B112 
B113 
B117 
B118 


Cifrado 
IPSEC 3DES 


Cifrado 
802.11 WEP 
RC4 


SSL Header 


HTTP Header 
Cifrado 

SSL RC4 e 
IPSEC 3DES 


HTTP Body 


SSL MAC 


ESP Trailer Cifrado 
IPSEC 3DES 


B133+L 
B134+L 
B137+L 
B138+L 
B149+L 
B50+L 1ICV 
B15341 
B154+L FCS 
B157+L 


ESP Authentication 


Figura 7. Formato de la trama 802.11. 


La figura 7 describe la trama 802.11 con los mecanismos 
de cifrado aplicados y la tabla II resume la profundidad de 
cifrado de todos los campos de los protocolos descritos. 


IV. MODIFICACIÓN EN EL CIFRADO DE LA INFORMACIÓN. 


A continuación proponemos una solución para eliminar la 
redundancia de cifrado sobre los campos con una profundidad 
de cifrado superior a 1. El criterio adoptado en esta solución 
es que un campo que deba ser cifrado por el servicio de 
seguridad de capa lo será si su profundidad de cifrado es 
igual a 0, es decir, sí no ha sido cifrado en capas superiores 
o es un campo introducido por el protocolo de capa. Este 
criterio permite mantener la seguridad de capas superiores al 
tiempo que elimina operaciones de cifrado en capas inferiores. 


A continuación detallamos nuestra solución en cada uno de 
los mecanismos de seguridad de capa (SSL, IPSEC y WEP) 
y que se recogen en la figura 8. 


IV-A. Modificaciones SSL. 


Todos los datos de la capa de aplicación que recibe SSL 
tienen una PC igual a O. Según el criterio adoptado, nuestra 
solución mantiene el cifrado SSL sobre el campo de datos 
de aplicación (L octetos) y sobre el campo SSL hash (16 


octetos). La PC para estos campos es igual a 1. 


IV-B. Modificaciones IPSEC 


IPSEC recibe dos campos con PC igual a 1, que son, datos 
de aplicación (L octetos) y SSL hash (16 octetos). A estos 
campos no se les aplicará cifrado. Por otra parte los campos 
cabecera SSL (5 octetos), ESP Trailer (4 octetos), cabecera IP 
(20 octetos) y cabecera TCP (20 octetos) tienen una PC igual 
a O, por lo que según el criterio indicado, IPSEC aplicará el 
cifrado y modificará la PC a 1. 


IV-C. Modificaciones en seguridad WEP 


Con la solución propuesta los campos cifrados por capas 
superiores que tienen una PC igual a 1 son los datos de 
aplicación (L octetos), SSL hash (16 octetos), la cabecera 
SSL (5 octetos), ESP Trailer (4 octetos), cabecera IP (20 
octetos) y la cabecera TCP (20 octetos). Estos campos, 
aplicando el criterio de diseño propuesto no se cifran. El resto 
de campos que sí cifra WEP y que tienen PC igual a O son 
cabecera LLC (8 octetos), nueva cabecera IP (20 octetos), 
cabecera ESP (16 octetos), y el campo ESP Auth (12 octetos). 


802.11 Header 


B25 Iv 


B29 LLC Header 


Encryption 
802.11 WEP 
RC4 


Ba7 NEW IP Header 


Bs7 ESP Header 


TP Header 


Encryption 


TCP Header IPSEC 3DES 
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B113 
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SSL Header 


HTTP Header 


Encryption 
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Bi33+L SSL MAC 
B1344+L 
B137+L 
B1384+L 
B1494+L 
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Encryption 
TPSEC 3DES 


ESP Trailer 


ESP Authentication Encryption 
802.11 WEP 


RC4 
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Figura 8. Formato trama 802.11 con modificación de cifrado. 


IV-D. Resumen de los cambios en la aplicación de los 
mecanismos de cifrado. 


Nuestra solución mantiene el cifrado SSL en la capa de 
transporte y suprime el cifrado de determinados campos a 
nivel IP (IPSEC) y a nivel MAC (WEP). En la tabla III se 
resume una comparativa del número de octetos total cifrados 
por los servicios de seguridad de capa antes y después de 
aplicar la solución presentada y referenciados a una longitud 
de datos de aplicación L. 
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Resumen de profundidad de cifrado 
Capa Protocolo Campo Profundidad de cifrado | Mecanismos de cifrado aplicados. 
APLICACION HTTP HTTP HEADER 3 SSL - IPSEC - WEP 
APLICACION HTTP HTTP BODY 3 SSL - IPSEC - WEP 
TRANSPORTE SSL SSL HEADER 2 IPSEC - WEP 
TRANSPORTE SSL SSL HASH E SSL - IPSEC - WEP 
TRANSPORTE TCP TCP HEADER 2 IPSEC - WEP 
RED IP IP HEADER 2 IPSEC - WEP 
RED IPSEC NEW IP HEADER 1 WEP 
RED IPSEC ESP HEADER 1 WEP 
RED IPSEC ESP TRAILER 2 IPSEC - WEP 
RED IPSEC ESP AUTH 1 WEP 
ENLACE LLC LLC HEADER 1 WEP 
MAC WEP ICV 1 WEP 
Tabla II 
PROFUNDIDAD DE CIFRADO 
| Longitudes de cifrado (octetos) 
| Capa Cifrado Longitud de datos | Cifrado Original | Nuevo Cifrado 
[ TRANSPORTE SSL (RC4) 41+L 16+L 16+L 
| IP TIPSEC-tunel (3DES) 113+L 65+L 49 
| MAC WEP-128 157+L 125+L 60 
Tabla II 
VARIACIÓN DE LA LONGITUD CIFRADO 
Longitudes de cifrado (octetos) 

Capa Cifrado Longitud| Nueva Longitud Nueva Longitud | Nueva Longitud| Nueva 
Origi- lon- Origi- lon- Origi- lon- Origi- lon- 
nal gitud nal gitud nal gitud nal gitud 
E=1 EL=1 L=200 L=200 L=800 L=800 L=1300 | L=1300 

TRANSPORTE | SSL (RC4) 17 17 216 216 s16 s16 1316 1316 

IP IPSEC- 66 49 265 49 865 49 1365 49 

tunel (DES) 

MAC WEP-128 126 60 325 60 925 60 1425 60 

SUMA octetos | — 209 126 807 325 2607 925 4107 1425 

Tabla IV 


LONGITUD CIFR 


Destacamos que en la solución presentada, IPSEC y 
WEP cifrarán datos con longitud fija de 49 y 60 octetos 
independientemente de la longitud de los datos de aplicación, 
siempre que a niveles IP y transporte se implementen IPSEC 
ESP en modo túnel y SSL respectivamente. 


En la tabla IV se muestra la longitud total de octetos 
cifrados por los mecanismos de seguridad en función de 
la longitud L. En nuestro escenario, para una longitud L y 
aplicando N mecanismos de cifrado, la estructura tradicional 
de seguridad cifra ((NxL)+209 octetos) con N=3. Al aplicar 
la solución propuesta, los mecanismos de seguridad cifrarán 
(L+126) octetos. La reducción de los octetos cifrados es del 
39,71% para una longitud L=1 octetos, de un 64,5% para 
L=800 octetos y de un 65,4 % para L=1400 octetos. El límite 
teórico de reducción del número de octetos cifrados, que 
correponde a una longotud L suficientemente grande con la 
que podemos despreciar el cifrado de las cabeceras, es del 
66,67 %. 


ADO VARIANDO L 


V. RESULTADOS. 


Hemos cuantificado que para una longitud de datos L, la ar- 
quitectura TCP/IP tradicional cifrará (NxL)+K octetos, siendo 
N el número de mecanismos de cifrado aplicados, L la longitud 
de datos y K una variable que dependen del overhead de los 
mecanismos de cifrado utilizados en el cifrado original. Como 
alternativa a esta redundancia de cifrado, hemos propuesto una 
solución que reduce el número de octetos cifrados a L+K”, 
siendo L la longitud de datos y K” una variable que depende 
del overhead de los mecanismos de cifrado utilizados al aplicar 
nuestra solución. La tabla V detalla los valores de N, K y K” 
en función de los mecanismos de cifrado utilizados y la figura 
9 representa las rectas que se obtienen al variar el valor de L. 
En las gráficas se indican los resultados correspondientes al 
cifrado sin aplicar nuestra solución sin referencia y referen- 
ciados como ”CL” los resultados obtenidos al aplicar nuestra 
propuesta. 
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Longitudes de cifrado 
Cifrado N K K | (NxD)+K | L+K” 
SSL+IPSEC+WEP | 3 | 206 | 125 3L+206 | L+125 
TIPSEC+WEP 2 | 148 | 104 | 2L+148 L+104 
SSL+WEP 2 89 73 21L+89 L+73 
Tabla V 


VALORES DEN, K Y K?”. 
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Figura 9. Longitud de Cifrado 


El escenario presentado en el apartado 1 implementa SSL, 
IPSEC y WEP por lo que las expresiones que cuantifican 
los octetos cifrados son 3L+206 y L+125. A partir de estas 
expresiones obtenemos la figura 10 que muestra la variación 
del número de octetos cifrados por los mecanismos de capa en 
función de la longitud de los datos de aplicación (L) y compara 
nuestra solución con la situación de cifrado sin aplicar la 
solución presentada. 
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Figura 10. Número total de octetos cifrados. 


VI. CONCLUSIONES Y TRABAJO FUTURO. 


En este artículo hemos demostrado que al aplicar simul- 
táneamente mecanismos de cifrado en diferentes capas se 
producen duplicidades, e incluso multiplicidades, en el cifrado 
de octetos. Hemos calculado que la longitud de cifrado, al 
aplicar mecanismos de cifrado en las capas TCP, IP y MAC, 
es (NxL)+K. Hemos propuesto una solución que reduce el 
cifrado a un orden L+K”. 

Nuestra solución requiere que las capas dispongan de 
información del cifrado realizado en las otras capas. Este 
problema requiere la aplicación del diseño Cross-Layer en el 
que las distintas capas intercambien información relativa a 
las operaciones de cifrado que realizan. La línea de trabajo a 
seguir consiste en el diseño de un algoritmo Cross-Layer que 
implemente la solución propuesta. Otro aspecto importante 
es la cuantificación del impacto del cifrado en términos de 
energía y rendimiento global y los beneficios que se obtienen 
al aplicar una solución que reduzca la cantidad de octetos 
cifrados. Debemos considerar otros servicios de seguridad y 
mecanismos de cifrado de capa con el objeto de cuantificar 
la longitud de datos cifrados y los costes de energía en los 
terminales inalámbricos y el rendimiento en el punto de 
acceso. 
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Resumen—La importancia de tener en cuenta la seguridad 
como requisito no funcional en el éxito de un producto software 
(PS) es un hecho cada día más notable. Existen varios estándares 
y aproximaciones en la comunidad científica a la definición de 
la seguridad como elemento de calidad de un PS, sin embargo 
existen diferencias y falta de cohesión entre ellas. En este trabajo 
se estudian las propuestas más importantes en este sentido con 
el objetivo final de proponer un modelo de calidad integrador 
para la seguridad en el ámbito de los PS. 

Palabras Clave—seguridad; modelo calidad seguridad; seguri- 
dad producto software 


I. INTRODUCCIÓN 


La seguridad es un requisito no funcional que tiene una 
repercusión extraordinaria en la calidad de los productos 
software. De hecho, la seguridad informática ha sido un campo 
que ha crecido enormemente desde los años 70, dando lugar 
a una gran cantidad de técnicas, modelos, protocolos, etc., 
que han venido acompañados también de una actividad muy 
pronunciada por parte de las organizaciones internacionales de 
normalización y certificación. Tanto es así, que como se indica 
en [1], se pueden encontrar numerosas organizaciones interna- 
cionales de estandarización que han producido una compleja 
estructura de estándares relativos a temáticas relacionadas con 
la seguridad informática, que cambian y se actualizan con 
mucha frecuencia. 

Existen numerosas definiciones de seguridad. Lo habitual 
es que todas ellas definan la seguridad en términos de otros 
conceptos relacionados. Por ejemplo, una definición tradi- 
cional es la de [2], que la define como la ”protección de 
información procesada por un computador frente a consultas 
no autorizadas, modificaciones inapropiadas o la falta de 
disponibilidad de un servicio en un momento dado”. Otra 
definición clásica es la ofrecida por [3], que considera la 
seguridad como un sub-factor de la calidad del software, 
y la define como ”la capacidad de los productos software 
para proteger los datos y la información para que personas 
O sistemas no autorizados no puedan leerla o modificarla y 
para que el acceso no sea rechazado a personal autorizado”. 
En ambas definiciones están presentes los conceptos de con- 
fidencialidad, integridad y disponibilidad. Sin embargo, hay 
otras definiciones algo más recientes que consideran además, 


otras propiedades importantes, como son la autenticación, el 
no repudio y la autorización y control de acceso [4]. Aunque la 
seguridad se puede interpretar como un aspecto estrictamente 
técnico, hay autores que piensan que es mucho más que eso, 
teniendo por el contrario una dimensión estratégica, resultando 
uno de los criterios más importantes en el gobierno de las 
TIC [5]. 

Sin embargo, aunque también se han desarrollado ampli- 
amente en las últimas décadas las técnicas y metodologías 
propias de la ingeniería del software, éstas no han considerado 
la seguridad como un aspecto importante del desarrollo, de- 
jando que la construcción metodológica del software se centre 
fundamentalmente en los requisitos funcionales, y algunos 
otros requisitos no funcionales, y relegando los requisitos de 
seguridad a un momento tardío en el proceso de desarrollo 
de software. Algunas propuestas interesantes que tratan la 
seguridad, aunque de manera parcial y sin ofrecer un claro 
seguimiento de esos aspectos de seguridad a lo largo del 
proceso de desarrollo incluyen [6-13]. 

Por lo tanto, se hace necesaria la creación de un modelo 
de seguridad (como componente de calidad) que claramente 
identifique una taxonomía de requisitos de seguridad que 
puedan ser identificados, modelados e implementados, junto 
al resto de requisitos, tanto funcionales como no funcionales. 

El objetivo de esta propuesta es analizar los modelos ex- 
istentes que definan la seguridad y sus componentes como 
aspectos que inciden en la calidad de los productos software, 
y construir un modelo unificado, completo y detallado que 
permita evaluar y mejorar este aspecto del desarrollo que 
resulta crítico para el éxito de muchos productos software. Este 
modelo, no incluirá aspectos relativos a técnicas de seguridad, 
amenazas de seguridad, políticas de seguridad, ataques de 
seguridad, etc., sino que fundamentalmente especificará las 
características de seguridad que nos puedan interesar de un 
producto software. 

Para ello, se ha organizado el resto del documento del 
siguiente modo: En la Sección II se presentan algunos de los 
modelos de seguridad más relevantes. Posteriormente, en la 
Sección III se analizan paso a paso y desde un punto de vista 
integrador todas las características que proponen los trabajos 
estudiados en la sección anterior y que darán lugar al modelo 
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de seguridad que se propone en la Sección IV. La Sección V 
refleja las conclusiones obtenidas de la evolución y desarrollo 
de la propuesta. 


TI. MODELOS DE SEGURIDAD RELEVANTES 


En esta sección se describirán los aspectos más importantes 
de los modelos de seguridad definidos en los principales 
estándares más aceptados sobre calidad del software y seguri- 
dad. 


A. ISO/IEC 9126 


Uno de los estándares con mayor reconocimiento para 
evaluar la calidad de los productos software es el ISO/IEC 
9126 [3]. Este estándar define tres tipos de calidad: la calidad 
interna, la calidad externa y la calidad en uso. El estándar 
define un modelo de calidad de productos software (tanto para 
calidad interna como externa) en términos de un conjunto de 
características (funcionalidad, fiabilidad, usabilidad, eficiencia, 
mantenibilidad y portabilidad). Este modelo, que ya cuenta 
con más de una década desde su creación, otorga muy poca 
importancia a la seguridad como factor de calidad de los 
productos software. 

En cuanto a la calidad en uso, el estándar la define como 
la capacidad de un producto software para permitir a ciertos 
usuarios conseguir sus objetivos con eficacia, productividad, 
seguridad y satisfacción en un contexto de uso específico. 
En este caso, también se hace una mención explícita a la 
seguridad, pero relativa al término inglés safety. 

Un resumen de dicho modelo puede verse en la Tabla I , 
donde la seguridad no es una característica del mismo. Sin 
embargo, sí aparece definida como una sub-característica de 
la funcionalidad. 


Tabla I 
MODELO DE SEGURIDAD DE LA ISO/TEC 9126 


Característica | Sub-característica | Sub-sub-característica 
Modelo de Calidad Interna y Externa 
Confidencialidad 
Funcionalidad Seguridad Integridad 
Disponibilidad 


Modelo de Calidad en Uso 
Seguridad (safety) 


B. SQuaRE - ISO/IEC 25010 


SQuaRE (Software Product Quality Requirements and Eval- 
uation - Requisitos y Evaluación de la Calidad de Productos 
Software) es una familia de estándares, que tienen como origen 
el estándar ISO/IEC 9126, y que define la calidad de un 
producto software como el grado en el que dicho producto 
satisface las necesidades implícitas y explícitas de sus difer- 
entes usuarios [14]. Este estándar está en proceso de creación, 
y todavía no están disponibles documentos definitivos, aunque 
ya se puede intuir con cierta precisión sus aspectos más 
destacables. 

Este estándar considera actualmente tres modelos de cali- 
dad: El modelo de calidad de productos software, el modelo 


de calidad en uso, y el modelo de calidad de datos. Cada 
uno de estos modelos es definido en términos de un conjunto 
de propiedades o características. Así, el modelo de calidad 
de productos software, considera entre sus características la 
seguridad y la fiabilidad, como destacables. En este modelo, 
el concepto de disponibilidad se incluye como una sub- 
característica de la fiabilidad. Por otro lado, el modelo de 
calidad en uso viene caracterizado por tres aspectos, que son la 
usabilidad, la flexibilidad y la seguridad (safety), este último 
de interés, con sub-características asociadas. Por último, el 
modelo de calidad de datos define un conjunto de carac- 
terísticas de las cuales son de interés las de confidencialidad 
y disponibilidad. 

Este estándar, a pesar de no estar centrado en la seguridad 
(como otros que se analizan a continuación) ya ofrece un 
conjunto más completo de propiedades de seguridad, como se 
puede ver resumido en la Tabla II, y le otorga a la seguridad un 
protagonismo como aspecto de calidad que no era reconocido 
en las versiones anteriores del estándar del que parte SQuaRE, 
al pasar a estar presente como una característica más en el 
modelo. 


Tabla II 
MODELO DE SEGURIDAD DE LA ISO/TEC 25010 


Característica Sub-característica 
Modelo de Calidad de Productos Software 
Confidencialidad 
Integridad 
No repudio 


Seguridad 


Responsabilidad 
Autenticidad 
Conformidad 

Modelo de Calidad en Uso 

Daño comercial 


Seguridad y salud del operador 


Seguridad (safety) Seguridad y salud pública 


Daño medioambiental 


Conformidad de seguridad (safety) 
Modelo de Calidad de Datos 
Confidencialidad 

Disponibilidad 


C. Modelo de Firesmith 


Un modelo propuesto por Firesmith [15], lejos de la 
vorágine de las organizaciones de estandarización, y más en 
un contexto científico, propone un modelo de la seguridad, 
como característica de la calidad del software, compuesto por 
un conjunto de sub-características que a su vez se dividen en 
sub-características, con la organización que se representa en 
la Tabla TIL. 

Cada elemento de la propuesta está debidamente definido, 
excepto las dos últimas sub-características de seguridad. 


D. ISO/IEC 15408 o Common Criteria 


Este estándar [16] no propone un modelo de seguridad, 
sino que propone un marco de trabajo para la evaluación 


272 


Tabla HI 
MODELO DE SEGURIDAD DE FIRESMITH 


Característica Sub-característica Sub-sub-característica 
Identificación 
Control de acceso Autenticación 
Autorización 
Detección de ataques 
No repudio 
Integridad de datos 
integridad miepndad de hardware 
Seguridad Integridad personal 


Integridad de software 


Auditoría de seguridad 


Protección física 


Privacidad o 
Confidencialidad 
Recuperación 
Continuidad 


de la seguridad de productos software y sistemas de infor- 
mación. El mismo no considera la seguridad como un requisito 
no funcional, sino todo lo contrario, define un conjunto de 
clases de componentes o requisitos funcionales de seguridad y 
también un conjunto de componentes de garantía de seguridad 
organizados en varios niveles de exigencia. Para este trabajo 
nos vamos a concentrar en las clases de requisitos funcionales, 
que se dividen en familias funcionales de seguridad, y que a su 
vez se dividen en componentes. Presentaremos a continuación 
algunas de las clases y familias, exponiendo un nivel adecuado 
para acercarnos al problema que nos atañe. 


+. Clase comunicaciones: Incluye familias de No Repudio 
de origen y recepción. 

+ Clase protección de datos de usuarios: Incluye familias de 
políticas y funciones de control de acceso; autenticación, 
importación/exportación, recuperación y transferencia in- 
terna de datos; políticas de protección de control de 
flujo, confidencialidad e integridad de datos en tránsito, 
protección e integridad de información residual y datos 
almacenados. 

e Clase de identificación y autenticación: Familias de aut- 
enticación, identificación y enlace entre usuarios; atribu- 
tos de usuario. 

e Clase de privacidad: Incluye familias de anonimato, pseu- 
doanonimato, enlace entre usuario y acciones, obser- 
vación por parte de otros usuarios. 

e. Clase de protección de seguridad de un elemento: Fa- 
milias de disponibilidad, confidencialidad e integridad de 
datos exportados; protección física, recuperación confi- 
able, repetición de borrado. 

e Clase de acceso a elementos: Familias de limitación, es- 
tablecimiento, terminación y bloqueo de sesiones, historia 
de accesos. 

+. Clase de canales y caminos seguros. 


E. MAGERIT versión 2 


Este documento [17], elaborado por el Consejo Superior de 
Administración Electrónica de las Administraciones Públicas 
de España, presenta una metodología de análisis y gestión de 
riesgos de los sistemas de información, que resulta un docu- 
mento de referencia tanto a nivel nacional como internacional 
(metodología oficialmente reconocida por la OTAN [18] y por 
la OCDE [19]) para la gestión de riesgos, y que es conforme a 
varias normas internacionales de gestión de la seguridad como 
es el caso de la ISO/IEC 13335 [20]. 

Esta metodología no ofrece un modelo de seguridad, pero si 
identifica una serie de aspectos que son cruciales para cumplir 
el objetivo de este trabajo. En primer lugar, MAGERIT 
identifica un conjunto de dimensiones de valoración, que 
son características o atributos que hacen valioso un activo, 
es decir, son facetas (sub-características) de seguridad que 
conviene proteger, en relación con los activos o elementos que 
constituyen valor dentro del contexto de las tecnologías de la 
información. En concreto, MAGERIT define las 7 dimensiones 
de valoración que se resumen en la Tabla IV, del siguiente 
modo: 


Tabla IV 
DIMENSIONES DE VALORACIÓN DE MAGERIT 


Característica Sub-característica 
Disponibilidad 
Integridad de datos 
Dimensiones Confidencialidad de los datos 


de Valoración Autenticidad de los usuarios del servicio 


de Activos Autenticidad del origen de los datos 


Trazabilidad del servicio 
Trazabilidad de los datos 


Un segundo aspecto, considerado por MAGERIT, y que 
resulta especialmente interesante para el trabajo elaborado en 
este informe es el relativo a las amenazas. Las amenazas 
representan el impulso que da lugar a requisitos de seguridad, 
por lo que, además de disponer de un modelo de seguridad 
compuesto de características, es importante también identificar 
un conjunto de posibles amenazas que darán lugar a requisitos 
de seguridad (cuando sean consideradas) y por lo tanto a 
artefactos de análisis, diseño e implementación en los sistemas 
que se desarrollen. 

En este sentido, MAGERIT define una taxonomía de ame- 
nazas clasificadas básicamente en desastres naturales, de ori- 
gen industrial y errores y fallos no intencionados de los 
usuarios y del propio sistema. 


F. Familia 27000 


La familia de normas ISO/IEC 27000 está compuesta de 
un conjunto de documentos, todos ellos relacionados con la 
gestión de la seguridad. En concreto, la 27000 [21] incluye la 
definición de un vocabulario común sobre gestión de seguri- 
dad, la 27001 [22] proporciona un modelo para establecer, 
implementar, operar, controlar, revisar, mantener y revisar 
los sistemas de gestión de seguridad de la información, la 
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27002 [23] ofrece un código de buenas prácticas, la 27003 [24] 
unas guías de implantación, la 27004 [25] es relativa a métricas 
para la gestión de la seguridad, la 27005 [26] es sobre 
gestión de riesgos, la 27006 [27] muestra un cuerpo para la 
certificación de la seguridad y la 27007 [28] ofrece guías 
de auditoría. Esta familia de normas (todavía incompleta) 
representa un esfuerzo por la agrupación y unificación de 
estándares relativos a la gestión de la seguridad, y que se 
pretende que sea modelo de referencia en el futuro. 


En su norma base, se define la seguridad de la información 
como la preservación de la confidencialidad, la integridad y la 
disponibilidad de la información. También considera, aunque 
en un menor nivel de importancia otras propiedades como la 
autenticación, la responsabilidad, el no repudio, y la fiabili- 
dad. Todas estas características se encuentran rigurosamente 
definidas en dicho estándar. 


G. COBIT versión 4.1 


COBIT (Control Objectives for Information and Related 
Technology) [29] es un conjunto de buenas prácticas para 
el manejo de información creado por la Asociación para la 
Auditoría y Control de Sistemas de Información (ISACA). 
Este documento ayuda a entender los Sistemas de Información 
(o tecnologías de la información) y a decidir el nivel de 
seguridad y control que es necesario para proteger los activos 
de las compañías mediante el desarrollo de un modelo de 
administración de las tecnologías de la información. Uno de 
los aspectos más desarrollados en COBIT es la protección de 
la seguridad de la información, que aunque no es el único 
aspecto, aparece destacado frecuentemente. De hecho, por 
ejemplo, COBIT define un conjunto de ”criterios de infor- 
mación” necesarios para conseguir los objetivos de negocio, 
y la mayoría son relativos a seguridad, ellos son: eficacia, 
eficiencia, confidencialidad, integridad, disponibilidad, con- 
formidad y fiabilidad. Todos estos conceptos se aproximan a 
la seguridad, aunque desde un nivel de abstracción muy alto 
y relativo al negocio y sus procesos. 

COBIT proporciona, además, un conjunto de procesos que 
contribuyen al gobierno de las tecnologías de la información, 
y son agrupados en diversas categorías. Uno de estos procesos 
es dedicado monográficamente a la seguridad (se conoce como 
DS5 Asegurar Seguridad de Sistemas), y para el cual se 
definen un conjunto de objetivos de control como son gestión 
y planificación de TI, gestión de identidades y cuentas de 
usuario, pruebas, vigilancia y control de seguridad, definición 
de incidencias de seguridad, gestión de claves criptográficas, 
prevención, detección y corrección de software malicioso, 
seguridad en redes, intercambio de datos sensibles y protección 
de la seguridad de la tecnología. Estos objetivos de control 
representan aspectos que deben ser tenidos en cuenta para 
garantizar la seguridad de las TI, de modo que existirán 
probablemente requisitos relativos estos objetivos de control 
en los sistemas de información, y se tendrá que desarrollar 
funcionalidad que los resuelvan. 


TI. ESTUDIO DE LAS CARACTERÍSTICAS 


En primer lugar, y como paso previo a la construcción 
del modelo de seguridad del software, hemos realizado un 
análisis de las distintas características, sub-características y 
sub-sub-características relacionadas con la seguridad, presente 
en los diversos modelos que hemos considerado en la sección 
anterior. Para ello, hemos construido la Tabla VI, donde se 
indican las distintas propiedades de seguridad de las prop- 
uestas analizadas (para mayor legibilidad, dichas propuestas 
han sido numeradas, y las correspondencias se ofrecen en 
la Tabla V), y se especifica en el cruce, la relación de 
cada una de esas propiedades con cada propuesta (en blanco 
cuando la propiedad no aparece en la propuesta, ”C” cuando 
aparece como característica, ”S” cuando aparece como sub- 
característica y ”U” cuando aparece identificado como parte 
de una sub-sub-característica). 

Las diferencias en la consideración de unas propiedades y 
otras como características, sub-características, o incluso como 
parte de sub-sub-características, se justifica básicamente por 
dos hechos: el primero tiene que ver con el cambio en la 
consideración de la seguridad que ha habido en los últimos 
años (eso justifica la variación entre la ISO/IEC 9126 y la 
ISO/IEC 25010), mientras que el segundo es la orientación de 
las propuestas, ya que aquellas que consideran la seguridad 
como sub-característica, son propuestas que consideran la 
calidad de manera general, mientras que las que consideran 
estas propiedades como características, es porque se trata de 
propuestas claramente orientadas a la seguridad. 


Tabla V 
ENLACE DE COLUMNAS DE LA TABLA VÍ CON LOS NOMBRES DE LAS 
PROPUESTAS 
No. Prop. | Nombre Propuesta 
1 ISO/IEC 9126 Modelo de Calidad Interna y Externa 
2 ISO/TEC 9126 Modelo de Calidad en Uso 
3 ISO/TEC 25010 Modelo de Calidad de Productos Software 
4 ISO/TEC 25010 Modelo de Calidad en Uso 
5 ISO/TEC 25010 Modelo de Calidad de Datos 
6 Modelo de Firesmith 
7 MAGERIT V2 
8 Familia 27000 
9 COBIT 


Analizando las distintas propiedades de la Tabla VI, se 
puede observar que en muchas ocasiones aparecen propiedades 
que comparten similitud con otras, y que se diferencian en 
algún matiz acentuado por una propuesta en concreto. Por 
ejemplo, la propiedad Confidencialidad, aparece definida en 
prácticamente todas las propuestas, pero en cambio MAGERIT 
la define como Confidencialidad de Datos, aunque compar- 
tiendo en esencia la definición. 

Por ello, se ha construido un grupo canónico de carac- 
terísticas que reduce el número inicial de propiedades de 
seguridad, uniendo aquellas propiedades relativas en esencia 
a aspectos muy cercanos, y dando lugar a propiedades de 
seguridad cuyo nombre probablemente ya está dentro del 
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Tabla VI 
COMPARACIÓN DE PROPIEDADES DE SEGURIDAD 


Propuesta 
Característica 


Anonimato 


Auditoría de seguridad 


clinical a 


Autenticación 


Autenticidad de origen de datos C 


Autenticidad de usuarios del servicio C 
Autenticidad S 
Autorización U 

Confidencialidad U S c U ¡Ae 
Confidencialidad de datos (8 
Conformidad S e 
Conformidad (safety) S 
Control de acceso S 


Daño Comercial S 


Daño medioambiental S 


Detección de Ataques S 
Disponibilidad U (e El EE 
Fiabilidad e € 
Identificación 
Integridad U S 
Integridad de datos 


Integridad de hardware 


Integridad personal 


Integridad de software 
No Repudio S 
Privacidad 


mu ja jajajeja 


Protección física 


n 
a 


Responsabilidad 
Seguridad S 

Seguridad (safety) G 
Seguridad y salud del operador 


aa 


Seguridad y salud pública S 
Trazabilidad de los datos e 
Trazabilidad del servicio € 


conjunto inicial de propiedades, pero cuya definición está 
enriquecida con los matices identificados en las propiedades 
iniciales de las que se parte (que en todo caso podrán actuar 
posteriormente como sub-características de ésta). Además, se 
han eliminado términos más generales que típicamente agregan 
algunos más detallados. En particular, se han suprimido los 
términos Seguridad y Seguridad con la orientación de Safety. 
También se ha eliminado la propiedad fiabilidad, ya que con- 
stituye una característica claramente diferenciada de seguridad, 
y así queda definida en el modelo de la ISO/TEC 25010. 

Otro análisis de la Tabla VI indica que entre todas las 
propiedades de la seguridad, se puede observar una clara agru- 
pación de aspectos relacionados con problemas de seguridad 
que son provocados intencionadamente, y por otro lado, en 
aspectos relacionados con problemas de seguridad fortuitos, 
que en principio pueden suceder sin que nadie los provoque 
intencionadamente (relacionados con el término inglés Safety). 
Todo esto redunda en otra categorización conforme al comen- 
tario anterior. Adicionalmente, en esta agrupación se considera 
la propiedad de conformidad, incluida en ambas categorías, ya 
que es importante desde ambos puntos de vista. 

Estas clasificaciones de canonización e integración de car- 
acterísticas, así como de separación según la intencionalidad 


de los problemas de seguridad serán finalmente depuradas en 
la sección siguiente, con la propuesta de modelo de calidad 
de seguridad. 


IV. MODELO PROPUESTO PARA LA SEGURIDAD DE 
PRODUCTOS SOFTWARE 


Tras el análisis y depuración de propiedades de seguridad 
llevados a cabo en la sección anterior, se presenta el mod- 
elo de seguridad (Tabla VID), compuesto por dos grupos de 
características de seguridad. El primer grupo es relativo a 
propiedades de seguridad definidas para proteger al sistema 
ante ataques de seguridad, y el segundo grupo se refiere a 
propiedades de seguridad definidas para proteger al sistema 
de fallos y situaciones fortuitas. Cada característica define a 
su vez un conjunto de sub-características, que se refiere a 
algún matiz específico que aun estando relacionado con la 
característica a la que pertenece, tiene algún aspecto clara- 
mente diferenciador. Se puede comprobar que el modelo 
elaborado comparte cierta similitud con la ISO/IEC 25010, 
pero la enriquece ampliamente con aspectos identificados en 
propuestas más especializadas en seguridad. 


Tabla VII 
MODELO DE SEGURIDAD MEDUSAS 


Características Sub-características 
e Autenti ió 
Autenticidad e Se A 
Identificación 
E seda Anonimat 
Confidencialidad A 2d 
Privacidad 


Conformidad 


Detección de ataques 


Protección ante ataques 


Disponibilidad 
Integridad de datos 
Integridad de hardware 
Integridad Integridad personal 
Integridad de software 
Protección física 
No Repudio 
Trazabilidad 


Conformidad (safety) 


Daño Comercial 


Daño medioambiental 


Seguridad y Salud del operador 


Seguridad y Salud pública 


Protección ante accidentes 


El modelo considera las siguientes características y sub- 
características, relativas a la protección de los sistemas de 
información ante ataques provocados, cuyas definiciones son 
determinadas a partir de la extracción de conceptos inte- 
gradores de los estándares y aproximaciones analizados en la 
Sección Il. 

. Autenticidad: Tiene que ver con el grado en el que 
se garantiza que los sujetos y recursos del sistema de 
información son auténticos. 

— Autenticación: Es relativo al grado en el que se ver- 
ifica la identidad de los sujetos antes de interactuar 
con ellos. 
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— Identidad: Es relativo al grado en que se identifican 
a los sujetos antes de interactuar con ellos. 


+. Confidencialidad: Es el grado en el que se asegura que la 
información es solamente accesible a sujetos autorizados. 


— Anonimato: Es el grado en que se impide el alma- 
cenamiento o descubrimiento de la identidad de los 
usuarios. 

— Privacidad: Es el grado en el que se asegura que la 
información de carácter personal, privado e íntimo 
es solamente accesible a sujetos autorizados. 


+ Conformidad: Es el grado en que los productos software 
se ajustan a los estándares, acuerdos, o regulaciones de 
leyes y otras recomendaciones similares de seguridad. 

+. Detección de ataques: Es el grado en que los intentos de 
ataque o los ataques realizados con éxito son detectados, 
almacenados y notificados. 

+. Disponibilidad: Es el grado en que se asegura que los su- 
jetos autorizados tienen acceso a los datos y aplicaciones 
en el momento en que lo requieran. 

+. Integridad: Es el grado en que se protege a los com- 
ponentes de los sistemas de información de alteraciones 
intencionada por parte de sujetos no autorizados. 


— Integridad de datos: Concepto de integridad aplicado 
a los datos. 

— Integridad del hardware: Concepto de integridad apli- 
cado a los componentes hardware del sistema. 

— Integridad del personal: Es el grado en que se protege 
la seguridad de las personas ante posibles reacciones 
del sistema provocados intencionadamente. 

— Integridad del software: Es el grado en que se 
protege los componentes de software de corrupción 
intencionada. 

— Protección física: Es el grado en que el sistema se 
protege a sí mismo y a sus componentes de ataques 
físicos. 


+. No repudio: Es el grado en que se impide que una parte 
de una interacción pueda repudiar algún aspecto de la 
interacción. 

e. Trazabilidad: Es el grado en que se asegura que las ac- 
ciones de un sujeto pueden ser trazadas inequívocamente 
y asociadas a dicho sujeto. 


Con respecto al modelo de seguridad, para el caso de carac- 
terísticas de seguridad relativas a la protección de los sistemas 
de información ante accidentes no provocados, básicamente se 
heredan las propiedades definidas por la ISO/TEC 25010 en el 
modelo de Calidad en Uso. 


V. CONCLUSIONES 


En el presente trabajo se han analizado los estándares y 
propuestas centradas en seguridad o con marcado enfoque 
en ella, donde se exponen un grupo de sus características 
inherentes y que han servido como base para el modelo de 
calidad propuesto. Dicho modelo es una propuesta integradora 
de conceptos con el fin de ofrecer una visión común en el área, 


tanto en lo que refiere a características y sub-características 
como a su definición formal. 


AGRADECIMIENTOS 


Esta investigación es parte de los proyectos: MEDUSAS 
(1IDI-200905357), financiado por el Centro para el Desarrollo 
Tecnológico Industrial, BUSINESS (PET2008-0136) conce- 
dido por el Ministerio de Ciencia e Innovación de España 
y SEGMENT (HITO-09-138) y SISTEMAS (PII2109-0150- 
3135) financiados por la Consejería de Educación y Ciencia 
de la Junta de Comunidades de Castilla-La Mancha. 


REFERENCIAS 


1] ITU. (2009). ICT Security Standards Roadmap Available: http://www.itu.int/ 
ITU-T/studygroups/com17/ict/index.html 

2] S. Castano, et al..Database Security: Addison-Wesley, 1995. 

3] ISO/IEC, ”ISO/IEC 9126-1. Information Technology. Software Product Quality. 
Part 1: Quality Model.,” ed, 1999. 

4] J. Swartz, "Security systems for a mobile world,” Technology in Society, vol. 25, 
pp. 5-25, 2003. 

5] S. Posthumus and R. v. Solms, ”A framework for the governance of information 
security,” Computers $ Security, vol. 22, pp. 638-646, 2004. 

6] J. Júrjens, ”UMLsec: Extending UML for secure systems development,” in UML 
2002 - The Unified Modeling Language, Model engineering, concepts and tools, 
J. Jézéquel, et al., Eds., ed Dresden, Germany: Springer. LNCS 2460., 2002, pp. 
412-425. 

7] J. Júrjens, Secure Systems Development with UML: Springer-Verlag, 2004. 

8] D. Basin, et al., "Model Driven Security: from UML Models to Access Control 
Infrastructures,” ACM Transactions on Software Engineering and Methodology, 
vol. 15, pp. 39-91, January 2006. 

9] M. Hafner, et al., "SECTET: An Extensible Framework for the realization of 
Secure inter-organizational Workflows,” Internet Research, vol. 16, pp. 491-506, 
2006. 

[10] E. Fernández-Medina and M. Piattini, "Designing Secure Databases,” Information 
and Software Technology, vol. 47, pp. 463-477, 2005. 

[11] C. Gutiérrez, et al., Towards a Process for Web Services Security,” Journal of 
Research and Practice in Information Technology, vol. 38, pp. 57-67, 2006. 

[12] D. Mellado, et al., ”A Common Criteria Based Security Requirements Engi- 
neering Process for Development of Securie Information Systems,” Computer 
Standards £ Interfaces, vol. 29, pp. 244-253, 2006. 

[13] A. Rodríguez, et al., ”Semi-Formal Transformation of Secure Business Processes 
into Analysis Class and Use Case Models: an MDA approach.,” Information and 
Software Technology, 2010. 

[14] ISO/IEC 25000, "Systems and software engineering - Software product Quality 
Requirements and Evaluation SQuaRE.” 

[15] D. Firesmith, ”Specifying Reusable Security Requirements,” Journal of Object 
Technology, vol. Vol. 3 (1), January-February., pp. 61-75, 2004. 

[16] ISO/IEC, ”ISO/IEC 15408. Common Criteria V3.,” 2009. 

[17] MAP, "Metodología de Análisis y Gestión de Riesgos de los Sistemas de 
Información (MAGERIT - v 2),” 2005. 

[18] CCN-CERT, "Últimos avances en ciberseguridad (9th NATO cyberdefense work- 
shop). Revista auditoria y Seguridad (www.revista-ays.com). n23-junio: 70-71.,” 
2008. 

[19] OECD, ”The promotion of a culture of security for information systems and 
networks in OECD countries. DSTI/ICCP/REG(2005)1/FINAL, Organisation for 
Economic Co-operation and Development.,” 2005. 

[20] ISO/IEC, ”ISO/IEC 13335 Information technology - Security techniques - Man- 
agement of information and communications technology security.,” 2004. 

[21] ISO/TEC, ”ISO/TEC 27000:2009. Information technology — Security techniques — 
Information security management systems — Overview and vocabulary,” ed, 2009. 
[22] ISO/IEC, "ISO/IEC 27001:2005. Information technology — Security techniques 
— Information security management systems — Requirements ”, ed, 2005. 

[23] ISO/IEC, ”ISO/IEC 27002:2005. Information technology — Security techniques 
= Code of practice for information security management,” ed, 2005. 

[24] ISO/IEC, ”ISO/IEC 27003:2010. Information technology — Security techniques 
— Information security management system implementation guidance,” 2010. 
[25] ISO/TEC, "ISO/IEC 27004:2009. Information technology — Security techniques 
— Information security management — Measurement,” ed, 2009. 

[26] ISO/IEC, "ISO/IEC 27005:2008. Information technology — Security techniques 
— Information security risk management,” ed, 2008. 

[27] ISO/IEC, ”ISO/TEC 27006:2007. Information technology — Security techniques — 
Requirements for bodies providing audit and certification of information security 
management systems,” 2007. 

[28] ISO/IEC, ”27007. Information technology — Security techniques — Guidelines for 
Information security management systems auditing. 

[29] ITGL (2007). COBIT 4.1: Marco de Trabajo, objetivos de control, directrices 
gerenciales y modelos de madurez. Available: www.itgi.org. 


276 


El Spyware como amenaza contra navegadores web 


Sergio Castillo-Pérez*, José Alfredo Múrcia Andrés, Joaquin Garcia-Alfaro'* 


* Universitat Autónoma de Barcelona, Edifici Q, 08193, Bellaterra 
Y Institut Telecom, Telecom Bretagne, 35576, Cesson-Sevigne, France 
F Universitat Oberta de Catalunya, Rambla de Poblenou 156, 08018, Barcelona 


Resumen—En la última década se ha realizado un progreso 
sustancial en Internet y en las tecnologías basadas en el paradig- 
ma web. Aplicaciones relacionadas con educación, salud, banca, o 
incluso con relaciones entre individuos o grupos sociales, pueden 
beneficiarse mediante el uso de dichas tecnologías. Sin embargo, 
los ataques a sistemas pueden comprometer drásticamente la 
privacidad de los usuarios que hacen uso de las tecnologías web. 
En este contexto, la infección de sistemas mediante Spyware es 
un claro ejemplo. En este artículo analizamos la amenaza del 
Spyware como vía para comprometer la seguridad y privacidad 
de los recursos de los navegadores web. 


I. INTRODUCCIÓN 


El uso del paradigma web en todos los modelos de negocios y 
organizaciones está convirtiéndose en un aspecto omnipresen- 
te. De hecho, su uso aparece como una estrategia emergente en 
todos los tipos de aplicaciones software de las compañías [1]. 
Éste permite el diseño de aplicaciones totalmente interactivas 
que pueden potencialmente ser usadas por miles de usuarios 
alrededor del mundo. La existencia de nuevas tecnologías para 
mejorar las características del paradigma web tradicional per- 
mite a los ingenieros del software concebir nuevos servicios, 
que no están restringidos a un sistema operativo específico. 
Sistemas tradicionales de información relacionados con la 
educación, salud, banca o incluso sistemas de emergencia, 
pueden beneficiarse de esta tecnología. 

La complejidad actual del paradigma web tiene, sin em- 
bargo, un impacto en la seguridad de los navegadores web 
y, de forma más precisa, en el tratamiento de sus recursos. 
Los ataques contra navegadores web pueden comprometer 
la seguridad y la privacidad de los usuarios. Esto puede 
tener serias consecuencias dada la omnipresencia de software 
malicioso, como el Spyware. El Spyware puede ser instalado 
de forma secreta en los navegadores web y robar datos 
sensibles, tales como identificaciones de usuarios, contraseñas 
o datos financieros [7]. Los navegadores web deben, por tanto, 
incluir mecanismos confiables para garantizar la seguridad 
y privacidad de sus usuarios. En este artículo damos una 
visión general de algunas técnicas usadas por el Spyware, y 
que pueden ser usadas por entidades maliciosas para violar 
la privacidad de los usuarios. Presentamos un escenario que 
muestra cómo la privacidad de un usuario accediendo a un 
servicio web puede ser violada por Spyware vinculado al 
navegador web. Seguidamente discutimos algunos mecanismos 
de defensa que pueden reducir el riesgo representado por la 
amenaza del Spyware. 


Organización del artículo — La sección II presenta la 
amenaza del Spyware y desarrolla nuestro escenario de 
motivación. La sección III presenta una visión general sobre 
mecanismos de defensa para reducir el riesgo de la amenaza 
del Spyware. La sección IV concluye el artículo. 


ll. SPYWARE 


El concepto Spyware (o software espía) es un término uti- 
lizado para catalogar al software malicioso (Malware) [11] 
que registra información de usuarios de forma no consentida, 
violando la privacidad de éstos. La información recolectada 
por este tipo de aplicaciones suele ser de distinta índole, 
tal como datos personales, números de tarjeta de crédito, 
hábitos de navegación web, contraseñas, pulsaciones de teclas, 
O captura de pantalla. Tal información es transmitida a terceras 
partes con finalidades como son el fraude electrónico [6], 
el marketing a través de publicidad web no consentida, u 
otras actividades normalmente maliciosas. Con la finalidad 
de conseguir su propósito, dicho software provoca diversos 
efectos en el comportamiento del sistema afectado, como 
la aparición de ventanas de navegación con publicidad no 
deseada, el secuestro del navegador web, instalación de puertas 
traseras (backdoors), modificación de los números de conexión 
a ISPs a otros con tarifas elevadas, etc. Asimismo, y con 
motivo de llevar a cabo su finalidad, la ejecución de estas 
aplicaciones suele conllevar la degradación del rendimiento del 
sistema, incrementando el uso de CPU, del espacio utilizado 
en disco, o del ancho de banda de red. 

A lo largo del tiempo, el Spyware ha evolucionado in- 
corporando sofisticados mecanismos propios de los rootkits. 
Estos mecanismos permiten al Spyware esconder su presencia 
a administradores o a software destinado a su detección. 
Así, estrategias como la ocultación de procesos, archivos o 
conexiones de red, o el uso de técnicas antidebugging o de 
criptografía, suelen ser características habituales en el Spyware 
de hoy en día. De forma análoga, y con el objetivo de no ser 
eliminados del sistema infectado, la inclusión de estrategias 
que dificultan su desinstalación son propiedades comunes en 
este tipo de software. Este conjunto de metodologías evasivas, 
junto a los mecanismos para la recopilación de información en 
si, suele conllevar la utilización de técnicas de programación 
que, en ocasiones, provocan cierta inestabilidad del sistema, 
dando lugar a un comportamiento inesperado de algunas 
aplicaciones. 
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En ocasiones, el concepto de Spyware es confundido con 
el de virus o gusano. A pesar de que ambos comparten una 
finalidad maliciosa, son radicalmente distintos en su modo 
de funcionamiento. Una de las diferencias primordiales que 
los distingue radica en el hecho de que el Spyware no suele 
auto-replicarse, es decir, un sistema afectado no propagará 
la infección a otros ordenadores. En el proceso de infección 
del Spyware podemos distinguir básicamente dos tipos de 
estrategia en función de si se requiere una interacción directa 
por parte del usuario, o si, por contra, la instalación se realiza 
de forma transparente. 

En el primer caso, el Spyware suele venir camuflado en 
programas supuestamente legítimos y que, sin el consenti- 
miento del usuario, es instalado junto a dicho software. Así, 
programas de tipo P2P, complementos para los navegadores 
web, software descargado de forma ilegal, o cracks, son 
ejemplos de programas que pueden esconder Spyware. En 
otras ocasiones, la vía de infección se basa en el acceso a 
una determinada web con componentes ActiveX o Applets 
Java especialmente preparados que, tras la autorización de su 
ejecución por parte del usuario, conllevan la instalación del 
Spyware. En cualquier caso, el proceso de infección requiere 
una aprobación de ejecución tácita por parte del usuario. 
La utilización de la ingeniería social suele estar presente en 
esta metodología, pudiéndose considerarse incluso un factor 
decisivo en el consecución del éxito para los atacantes. De 
esta manera, los atacantes utilizan estrategias para persuadir a 
los usuarios a descargar determinado software, o realizar de- 
terminadas acciones que conlleven la instalación del Spyware. 

En el segundo caso, los mecanismos de infección del 
Spyware se basan en la explotación de vulnerabilidades en 
el software. De esta manera, la visita a una determinada web 
preparada haciendo uso de un navegador vulnerable, o la aper- 
tura de un archivo especialmente preparado mediante software 
que incluya deficiencias de seguridad, pueden provocar la 
ejecución de código arbitrario que conduzca a la instalación 
del Spyware. En este proceso de infección, la instalación del 
software espía suele pasar totalmente desapercibida para el 
usuario afectado, sin requerirse ningún tipo de acción a realizar 
que puede considerarse motivo de sospecha. Comúnmente, 
esta estrategia suele estar ligada a otros ataques previos como 
son la redirección mediante XSS o el DNS Spoofing entre 
otros. Una vez el proceso de infección ha tenido éxito, el 
software espía capturará la información de su interés, y la 
utilizará según la finalidad para la que fue programado. En 
base a los mecanismos que se usan para interceptar esta 
información, y de las estrategias utilizadas para evadir la 
detección y/o desinstalación, distinguimos entre Spyware en 
modo usuario y Spyware en modo de kernel. 


Spyware en modo usuario — A esta categoría pertenece 
la mayor parte del Spyware que encontramos hoy en día, 
dado que su programación es más sencilla. Adicionalmente, 
dado que se ejecutan en modo de usuario, su detección y 
eliminación desentraña menos complejidad. Las estrategias 
empleadas en esta categoría para interceptar información, o los 


mecanismos para evadir su detección/desinstalación se basan 
principalmente en desviar el flujo de ejecución de las aplica- 
ciones, cediendo el control a determinado código del Spyware. 
Para esto, existen básicamente dos técnicas. La primera se basa 
en modificar las direcciones de memoria donde son mapeadas 
las funciones de las librerías compartidas y utilizadas por las 
aplicaciones. En el segundo caso, la metodología se sustenta 
en aprovechar mecanismos de extensión que proporcionan 
determinados programas. Estos mecanismos permiten ceder 
el control a cierto código al producirse eventos asociados a 
dicha aplicación, permitiendo extender las funcionalidades del 
software de forma sencilla. Esta idea, que dota de flexibilidad 
a los programas, puede ser usada de forma maliciosa por parte 
del Spyware. 


Spyware en modo de kernel — El Spyware en modo de 
kernel es conceptualmente igual que el Spyware en modo 
usuario, en el sentido que su funcionamiento se basa en 
desviar el flujo de ejecución de las aplicaciones. De nuevo, la 
ejecución es desviada a código del Spyware, el cual captura 
u oculta información en función de sus necesidades. La 
diferencia principal entre las dos categorías se basa en que 
en esta segunda el proceso de intercepción de información 
o evasión se realiza con un mayor nivel de privilegios. 
Concretamente, el código del software espía es cargado y 
ejecutado en el espacio de direcciones del núcleo del sistema 
operativo. Precisamente, esta característica de ejecución con 
privilegios de sistema les proporciona una mayor resistencia 
a ser detectados o eliminados, ya que las herramientas de 
detección o eliminación suelen ejecutarse en espacio de 
usuario. Esto implica una mayor complejidad en su código, 
lo que los hace menos comunes. La forma más habitual de 
desviar el flujo de ejecución por este tipo de Spyware se 
basa en modificar las tablas que contienen las direcciones 
asociadas a las llamadas al núcleo (syscalls). 


IT-A. Ejemplo de infección de un navegador web 


Con el objetivo de ilustrar cómo la privacidad de un usuario 
puede ser vulnerada mediante Spyware, describimos en esta 
sección un hipotético escenario donde se pone de manifiesto 
este hecho. La técnica utilizada por el Spyware para inter- 
ceptar la información se basará en explotar los mecanismos 
de extensión de ciertos programas — en nuestro caso, del 
navegador web. Esta característica está presente en la mayoría 
de los navegadores, y permite facilitar la adición de mejoras 
— comúnmente llamadas extensiones O complementos — por 
terceros programadores. Para conseguir esto, la rutina principal 
del navegador delega el flujo de ejecución a las nuevas funcio- 
nes de las extensiones ante ciertos eventos, permitiéndoles la 
lectura y la modificación del DOM (Document Object Model). 
Así, por ejemplo, se puede ceder el control del navegador 
durante la carga de una web, la carga/descarga de archivos, 
etc. De la misma manera que las extensiones legítimas, esta 
tecnología puede ser explotada por el Spyware para introducir 
sus rutinas de captura de información. 
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Supongamos que un usuario malicioso desea obtener núme- 
ros de tarjetas de crédito válidos con el objetivo de perpetrar 
fraude electrónico. Asumamos también que dicho usuario 
malicioso descubre una vulnerabilidad asociada a una versión 
particular de un navegador web que permite la ejecución 
de código arbitrario. Analizando la vulnerabilidad, el usuario 
malintencionado podría preparar varios servidores web que 
contengan el código necesario para explotarla, así como forza- 
ría a usuarios a visitar dichos servidores (e.g., mediante el uso 
de ingeniería social [6]). El acceso de las víctimas a estos 
servidores conllevaría la instalación del Spyware mediante 
la explotación de la vulnerabilidad. El objetivo del código 
malicioso instalado sería capturar y enviar hacia un sistema 
remoto los números de tarjeta de crédito introducidos por los 
usuarios durante sus transacciones electrónicas. En este con- 
texto, el Spyware podría emplear los mecanismos de extensión 
del navegador con el propósito de conseguir su objetivo. 

Para garantizar el éxito del escenario anterior, el atacante 
debe persuadir a un número elevado de potenciales víctimas 
(1.e., usuarios con un navegador vulnerable) a visitar los ser- 
vidores preparados. A mayor número de víctimas persuadidas, 
mayor será el éxito del atacante. El factor tiempo también es 
un elemento decisivo en este proceso, dado que tan pronto 
como la vulnerabilidad sea reportada y corregida por los 
usuarios, menor será la probabilidad de éxito. Con la finalidad 
de incrementar la velocidad del proceso de infección, otras 
técnicas pueden ser utilizadas, tales como en envenenamiento 
de DNS, el envío de correo no solicitado (spam), o el cross- 
site scripting, redirigiendo a los usuarios a los servidores 
preparados. 

Después de la infección, el Spyware — visto ahora como 
una extensión del navegador — permanece activo mientras 
analiza los datos que el navegador recibe o envía, a la espera 
de información de transacciones electrónicas (1.e., números de 
tarjetas de crédito, fechas de expiración, contraseñas, etc.). 
Toda la información capturada por el Spyware será enviada 
una vez post-procesada y protegida hacia un sistema remoto 
controlado por el atacante. Debemos notar que, a pesar de 
que el navegador puede usar criptografía para garantizar la 
autenticidad, integridad y confidencialidad de la información 
intercambiada con los servidores de comercio electrónico (e.g., 
usando el protocolo SSL/TLS), esto no protege la información 
robada por el Spyware. 

Sí analizamos el uso de SSL/TLS en el modelo de capas 
de TCP/IP, podemos observar que la información permanece 
protegida entre la capa de aplicación (HTTPS) y la capa de 
transporte (TCP). Sin embargo, dado que el Spyware que 
infectó el navegador es ejecutado en la capa de aplicación (1.e., 
HTTPS), éste intercepta la información antes de ser protegida 
por SSL/TLS. Asimismo, cabe destacar que el Spyware no 
provocará ningún mensaje sospechoso asociado a los certifi- 
cados digitales de SSL/TES, ya que el proceso de verificación 
no se ve afectado por la infección. De forma similar, el uso de 
códigos de verificación, tales como CVC2, CVV o CID, no 
ayudan tampoco a detectar o prevenir actividades maliciosas 
asociadas a un posible Spyware. 


III. TÉCNICAS DE PREVENCIÓN 
IFA. Mecanismos genéricos 


Podemos considerar tres métodos principales para prevenir 
nuestros sistemas de las infecciones de Spyware. En primer 
lugar, fomentar las buenas prácticas por parte de los usuarios, 
manteniendo actualizado tanto el sistema operativo como las 
aplicaciones, impedir las descargas de software de fuentes 
no fiables o ignorar los correos y contenidos adjuntos de 
remitentes desconocidos. Desafortunadamente, estas prácticas 
no son cumplidas muchas veces por los usuarios, ni tampoco 
son completamente efectivas. 

Otras formas de prevención, más técnicas, se basan en el 
diseño de patrones de protección. El objetivo de estos patrones 
es impedir la infección de un sistema o bien reducir el daño 
de la infección. Podemos agrupar dentro de esta categoría la 
utilización de anillos de protección. Dichos anillos establecen 
una estructura de confianza por capas en el sistema operativo y 
se complementan con hardware específico para poder realizar 
una separación efectiva entre procesos de confianza y procesos 
sospechosos. A través de esta solución, se pueden ofrecer dis- 
tintos niveles de acceso a los recursos del sistema. De hecho, 
los anillos se organizan de forma jerárquica, estructurando 
aquellos dominios más privilegiados y confiables hasta los de 
menores privilegios y nivel de confiabilidad. De este modo, 
se reduce el riesgo de que procesos de tipo Spyware ataquen 
al núcleo del sistema operativo (lo que les permitiría obtener 
el control del sistema al completo [4]). Estos métodos han 
demostrado que, aunque reducen las consecuencias de una 
infección, no son totalmente efectivos. 

El tercer mecanismo genérico, pensado especialmente para 
complementos o extensiones de software, consiste en verificar 
la autenticidad del código que se está ejecutando. Una primera 
solución consiste en la utilización de firmas digitales. Estas 
firmas se asociarán al código que ha de ser ejecutado y 
permiten verificar su autenticidad [17]. Para aquel código que 
no haya sido firmado, los usuarios deberán decidir entre: (1) 
no usar sus funcionalidades, o (2) exponerse a ciertos niveles 
de riesgo si dicho código es ejecutado. Con esta finalidad, 
se han dedicado esfuerzos a la investigación de mecanismos 
de tipo PCC (Proof-Carrying Code) y MCC (Model-Carrying 
Code). Ambas soluciones ofrecen una infraestructura para 
probar que el código se comportará de manera segura antes 
de su ejecución. Estas técnicas resultan eficientes en general 
a su aplicación al código móvil, pero ineficientes en el caso 
navegadores web [13]. 


HNFB. Mecanismos específicos 


Ante la ineficiencia de los métodos genéricos, las tendencias 
actuales se centran en la investigación de aplicaciones auto- 
máticas capaces de detectar y aislar código de tipo Spyware. 
Según la estrategia de análisis que utilicemos para la detección, 
podemos clasificar estos métodos en dos categorías principa- 
les: detección basada en análisis sintáctico (también conocida 
como detección de patrones o firmas) y detección basada en 
análisis semántico (detección por comportamiento). 
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Análisis Sintáctico — Consiste en la comparación del código 
a ejecutar contra una base de datos de firmas asociadas a 
código malicioso. El mayor inconveniente asociado a esta 
primera solución, al igual que ocurre con la totalidad de 
sistemas de detección basados en firmas, es la dependencia 
de una actualización periódica de la base de firmas. Por otro 
lado, la detección efectuada por este tipo de propuestas es fácil 
de evadir mediante técnicas de ofuscación de código [10], tales 
como el polimorfismo y el metamorfismo. 


Análisis Semántico — Consiste en modelar la interacción de 
código binario con el sistema — a partir del cual se determina 
si se trata de software malicioso. Esta estrategia supera las 
deficiencias del análisis sintáctico, dado que las mutaciones 
no afectan al comportamiento final del Spyware. Por esto, 
esta estrategia es conocida también como detección basada en 
comportamiento. En función de cómo la información para el 
modelado es obtenida podemos encontrar dos categorías [5]: 
(1) análisis dinámico y (2) análisis estático. 

Dentro de la primera categoría, encontramos, por ejemplo, 
el trabajo presentado por Vogt et al. en [12]. La propuesta 
consiste en un mecanismo de prevención de ataques XSS 
orientados al robo de información de usuario. Más concreta- 
mente, el mecanismo consiste en la utilización de un marcado 
de datos para la construcción y análisis de modelos dinámicos. 
Este mecanismo sufre, sin embargo, grandes deficiencias de 
rendimiento que lo hacen impracticable para la protección 
contra el Spyware en forma de extensiones de navegador. De 
hecho, el gran número de extensiones utilizadas actualmente 
en navegadores tales como Mozilla Firefox [13], hace que la 
solución propuesta por Vogt et al., basada en la pre-evaluación 
e interpretación de cualquier código ejecutable que trate de 
interactuar con los recursos del navegador, resulte a la práctica 
muy ineficiente. Una mejora propuesta por Russo ef al. en [14] 
trata de mejorar dicho rendimiento a partir de una reducción 
de las operaciones a monitorizar. En este caso, se propone 
la monitorización de tan sólo aquellas operaciones que in- 
teractúan con el DOM (Document Object Model) asociado a 
cada ejecución, redefiniendo su semántica. La propuesta no 
se centra únicamente en ataques de tipo Spyware mediante 
inyección de código malicioso, sino que más bien ofrece un 
mecanismo general para prevenir cualquier flujo considerado 
como de robo de información. 

En [16], Moshchuk et al. proponen una estrategia de análisis 
basada en la utilización de dispositivos de tipo proxy. Estos 
dispositivos interceptan y analizan el contenido dirigido desde 
las aplicaciones web hacia los recursos del navegador. En 
el supuesto que dicho contenido no pueda ser analizado de 
manera estática, por motivos de rendimiento, por ejemplo, 
se propone realizar un renderizado a través de máquinas 
virtuales. Éstas se encargarán de supervisar los efectos de la 
ejecución del contenido interceptado, y determinarán si debe 
ser aceptado o rechazado. A diferencia de otros métodos que 
tratan de prevenir la intercepción de información confidencial, 
la propuesta se centra en evitar la instalación dentro del 
navegador de Malware procedente de la web analizada. Ciertas 


limitaciones relacionadas con el indeterminismo del paradigma 
web actual, ya que el flujo de ejecución puede variar en 
función del contexto y la interacción con los usuarios, podrían 
hacer impracticable este tipo de propuestas, debido al alto 
número de falsos positivos y negativos que se pueden llegar a 
generar. 

Otras aproximaciones para la supervisión en tiempo de 
ejecución presentadas por Kirda ef al. en [8], plantean un 
mecanismo de detección de Spyware aplicado específicamente 
a los componentes internos del navegador Internet Explorer 
(concretamente, las bibliotecas BHO — Browser Helper Ob- 
ject — asociadas al navegador). Esta solución propone una 
supervisión híbrida a partir de un análisis tanto dinámico como 
estático. Mediante el análisis dinámico, se supervisa la inter- 
acción de los componentes con el navegador, registrando las 
funciones COM (Component Object Model) que son invocadas 
como respuesta a los eventos de un usuario. Este registro 
permite identificar eventos específicos, que son posteriormente 
analizados más en detalle, a partir de un modelo estático. Este 
segundo análisis concluye con la creación de un grafo de flujos 
que caracteriza las reacciones asociadas a cada evento. 

Nos gustaría destacar, por último, la propuesta presentada 
en [13] por Ter et al.. Esta propuesta ofrece protección de 
confidencialidad e integridad de los datos del usuario mediante 
la supervisión del acceso a datos y servicios realizados por 
extensiones de navegadores Mozilla Firefox a través de 
componentes XPCOM (Cross Platform Component Object 
Model) de Mozilla. La novedad de esta propuesta reside en la 
utilización de firmas del usuario asociadas a las extensiones 
del navegador. Estas firmas serán supervisadas tanto en el 
proceso de instalación de las extensiones, como durante la 
carga y ejecución de las extensiones. El mayor inconveniente 
relacionado con la propuesta, al igual que sucede con los 
mecanismo de prevención genéricos tratados en la sección 
IM-A, es la dependencia del buen comportamiento por parte 
de los usuarios, lo que en general comporta el fracaso de la 
medida de prevención. 


IV. CONCLUSIONES 


En este artículo se ha presentado un análisis de soluciones 
existentes contra la infección de sistemas mediante código 
malicioso (Malware) de tipo Spyware. El concepto de Spyware 
(o software espía) ha sido presentado como una evolución 
de Malware tradicional, cuyo objetivo es la interceptación no 
consentida de información perteneciente a los usuarios de los 
recursos de un navegador web. Dicha interceptación pretende 
violar, por lo tanto, la privacidad de usuarios de aplicaciones 
web relacionadas con educación, salud, banca, o redes socia- 
les. Se han analizado a continuación algunas de las técnicas 
que pueden ser utilizadas por código Spyware para infectar los 
recursos de un sistema. Finalmente, se ha concluido el análisis 
con un resumen de soluciones generales para la prevención 
de este tipo de infecciones. Una presentación más elaborada 
de nuestro estudio así como los resultados iniciales de una 
propuesta propia serán tratados en un informe futuro. 
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Resumen—Actualmente, la seguridad de la información es uno 
de los pilares principales en la gestión de las organizaciones. La 
evolución de los sistemas conlleva un aumento de su complejidad, 
y esto a su vez ha derivado en un incremento de los ataques a los 
sistemas de información, ya que hay muchas más posibilidades 
de que los atacantes encuentren nuevas vulnerabilidades. Por 
todo esto, es necesario proveer a los diseñadores de sistemas 
de soluciones fiables para minimizar este número de ataques y 
conseguir un menor impacto en su organización. Los patrones 
de seguridad son un buen mecanismo para aportar soluciones 
a problemas concretos de seguridad, ya que proporcionan 
soluciones estructuradas que solventan problemas recurrentes. 
Existen muchas propuestas enfocadas a la creación de nuevos 
patrones de seguridad, pero en la actualidad no se utilizan unas 
pautas homogéneas para realizar su descripción. Además, la 
mayoría de patrones existentes difícilmente pueden ser aplicables 
en el diseño de sistemas complejos, ya que en su descripción 
no contemplan la complejidad de las instalaciones reales. En 
este artículo se va a realizar una síntesis de un conjunto de 
propuestas que describen patrones de seguridad, basada en una 
revisión sistemática realizada anteriormente. Posteriormente se 
va a realizar un análisis en relación al contexto en el que se 
utilizan los patrones de seguridad, las plantillas y elementos que 
se usan a la hora de describir este tipo de patrones y además se 
estudiará la aplicabilidad de éstos en entornos reales. Finalmente 
se realizará una discusión para detectar las carencias ofreciendo 
a su vez una serie de propuestas de mejora. 

Palabras Clave—patrones, patrones de seguridad, seguridad de 
la información. 


I. INTRODUCCIÓN 


En los últimos años los avances tecnológicos están mejo- 
rando multitud de aspectos relacionados con el diseño y 
desarrollo de los Sistemas de Información (SI), provocando 
un crecimiento de la funcionalidad y aplicación de la que son 
dotados estos sistemas. Este crecimiento conlleva un aumento 
de la complejidad de los SI, incrementando el impacto de 
los ataques informáticos, ya que los atacantes tienen más 
posibilidades de encontrar nuevas vulnerabilidades en los 


sistemas, tales como Cross-Site Scripting, inyección de código, 
ejecución de ficheros maliciosos, etc. [1]. 

Por esta razón, la seguridad de la información es una de 
las principales preocupaciones que tienen las organizaciones 
en los últimos años. Por un lado, las compañías quieren evitar 
que su información esté en peligro y por otro lado, hay un 
incremento de ataques informáticos debido a los beneficios que 
pueden obtener los atacantes con la información que sustraen 
de las organizaciones. Debido a estos ataques, los diseñadores 
de SI deben incluir requisitos de seguridad a la hora de diseñar 
sus sistemas, es decir, deben asegurar la confidencialidad, 
integridad y disponibilidad de los datos siempre que sea 
necesario, para así, proteger los activos de información de la 
organización. La importancia en el diseño de sistemas seguros 
ha aumentado desde que la mayoría de los ataques a sistemas 
de software están basados en vulnerabilidades causadas por 
un deficiente diseño y desarrollo de las funcionalidades de las 
que se dota a los sistemas [2]. Para evitar estas deficiencias, 
los diseñadores de SI necesitan elaborar soluciones específicas 
para resolver problemas relacionados con las vulnerabilidades 
de seguridad, y así minimizar el número de ataques exitosos 
contra sus SL. 

Los patrones son una buena forma de satisfacer esta necesi- 
dad, ya que describen un problema que ocurre una y otra vez 
en un entorno, proporcionando una solución documentada y 
validada que puede ser usada múltiples veces [3]. Una de las 
principales ventajas de los patrones es que combinan expe- 
riencia y buenas prácticas en el diseño de SI [4], haciéndolo 
más eficiente. También es importante resaltar que los patrones 
no son una solución a un problema propuesto, sino una guía 
homogénea que documenta cómo problemas similares fueron 
resueltos anteriormente. 

Por lo tanto, los diseñadores de SI podrían usar patrones 
de seguridad para obtener soluciones fiables relacionadas en 
este campo, ya que son un buen mecanismo para optimizar 
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el proceso de decisión a la hora de resolver un problema 
de seguridad recurrente. Otra ventaja que encontramos en 
los patrones de seguridad es que incorporan un conocimiento 
extenso acumulado sobre seguridad de forma estructurada, 
proporcionando una serie de pautas para el diseño, construc- 
ción y evaluación de SI seguros [5]. 

La utilización de patrones de seguridad como guía para 
diseñar un SI seguro es una práctica bastante extendida [6, 
7, 8, 9]. De hecho, en los últimos años, el número de 
patrones de seguridad publicados ha crecido de manera con- 
siderable [10, 11, 12, 13, 14]. Sin embargo, existe una gran 
variedad y diversidad en las pautas de descripción de cada 
una de las propuestas [15, 16, 17, 18], incluso, en repetidas 
ocasiones, se han propuesto varios patrones diferentes que 
dan respuesta al mismo conjunto de requisitos o problemas 
de seguridad [19, 20], es decir, existe una superposición de 
soluciones. 

En este artículo se va a realizar una síntesis sobre las princi- 
pales propuestas que describen patrones de seguridad, basada 
en una revisión sistemática que se ha realizado previamente, 
siguiendo la propuesta de [21]. El objetivo principal del trabajo 
que aquí se presenta es realizar un análisis sobre el contexto 
en el que se emplean los patrones de seguridad, las plantillas 
utilizadas para describirlos y los elementos usados en estas 
descripciones. Adicionalmente, se va a comprobar cuántas 
propuestas están basadas y validadas en casos reales y cuántas 
en ejemplos teóricos. Este estudio ayudará a verificar la 
aplicabilidad que tienen los patrones de seguridad analizados 
en procesos de diseño de ST reales. 

El resto del artículo se organiza de la siguiente manera. 
En la Sección II se realiza una síntesis de un conjunto de 
propuestas que describen patrones de seguridad. La Sección HI 
muestra los resultados obtenidos y expone una discusión sobre 
los mismos. Finalmente, la Sección IV presenta las principales 
conclusiones y los trabajos futuros. 


II. SÍNTESIS DE PROPUESTAS DE PATRONES DE 
SEGURIDAD 


En esta sección se va a realizar una síntesis de las princi- 
pales propuestas que describen patrones de seguridad. Debido 
a la diversidad de soluciones que se proponen, agruparemos 
los trabajos según la problemática que solucionan los patrones 
que describen. 


A. Patrones de seguridad para comunicaciones seguras 


En este apartado se han agrupado los artículos relacionados 
con soluciones de seguridad centradas en el ámbito de las 
comunicaciones entre los distintos sistemas, y el envío y 
recepción de mensajes que realizan. 

En [22] se presentan cuatro patrones de seguridad que 
pueden ser utilizados para el diseño seguro de sistemas VoIP, 
ya que proponen soluciones que pueden controlar muchos de 
los posibles ataques brindando un entorno de trabajo para 
ayudar a los diseñadores a aplicar la seguridad en sus SI. 

En [23] se proponen tres patrones de diseño para las 
implementaciones de sistemas VoIP en relación con problemas 


de seguridad específicos. Se propone una técnica de cifrado y 
descifrado para paquetes de voz y añaden una nueva propuesta 
de generación de claves. También desarrollan un módulo de 
IPsec para sistemas VoIP en entornos Cliente/Servidor. 

En [24] se presenta un patrón para reforzar el canal de 
comunicaciones entre diferentes sistemas. Este patrón puede 
ayudar a los diseñadores de SI agregando controles de seguri- 
dad en la fase de procesado del flujo de datos. 


B. Patrones de seguridad para control de acceso e identifi- 
cación Seguros 


En este apartado se incluyen trabajos que muestran patrones 
para aumentar la seguridad de los SI, reforzándolos con 
mecanismos efectivos de identificación, autorización, auten- 
ticación y control de acceso. 

En [25] se propone un lenguaje de patrones para el sistema 
de gestión de identidades, compuesto por tres patrones. Este 
lenguaje de patrones está basado en SAML (Security Assertion 
Markup Language), que proporciona un formato específico 
para la comunicación de información acerca de la identidad 
de los diferentes dominios de seguridad. 

En [26] se describe una solución de control de acceso, para 
los datos generados por sensores inalámbricos. Esta propuesta 
está formada por tres patrones de seguridad que definen un 
modelo abstracto de control de acceso basado en criptografía. 

En [27] se propone un patrón de seguridad que describe el 
uso de la identificación de la información de credenciales para 
definir la autenticación y el control de acceso. Este patrón está 
descrito para ser usado en sistemas distribuidos con el fin de 
asegurar estos requisitos. 

En [28] se describen varios patrones para abordar aspectos 
relativos a las sesiones en modelos de control de acceso. 
Los autores muestran un patrón que controla el acceso de 
las diferentes sesiones, describiendo cómo una sesión puede 
limitar el derecho de un usuario. Además, se utilizan dos 
patrones más, que combinados con el patrón anterior, pueden 
constituir un patrón específico de control de acceso. Por 
último, esta propuesta muestra un entorno de trabajo real 
basado en el conjunto de patrones descrito. 


C. Patrones de seguridad para garantizar la privacidad 


En este apartado se incluyen los trabajos que proponen 
soluciones al problema de la privacidad tratando de preservar 
este aspecto utilizando patrones de seguridad. La privacidad es 
muy relevante en los intercambios de datos personales entre 
los usuarios y sistemas. 

En [29] se presenta un conjunto de patrones para la es- 
tandarización del desarrollo de políticas de privacidad con el 
fin de ser utilizado en sitios web. Estos patrones consideran 
principalmente aspectos relacionados con la seguridad, la 
información del usuario y la privacidad. Además, los autores 
muestran un ejemplo ficticio de una política de privacidad en la 
que se combinan todos los patrones descritos en la propuesta, 
pudiendo ser aplicada en un sitio web. 

En [18] se presentan dos patrones de seguridad: uno para 
la manipulación de cookies, que protege la identidad de los 
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usuarios cuando tienen acceso a un sitio web y otro, que 
permite a los usuarios utilizar un servicio de correo electrónico 
sin revelar su propia identidad. 

En [30] los autores enfocan su trabajo en mejorar los 
patrones de privacidad existentes. Además, para reforzar este 
escenario se describen tres patrones adicionales. Estos nuevos 
patrones pueden ayudar a preservar la privacidad pretendiendo 
que las organizaciones online, los diseñadores de páginas web 
y los usuarios puedan utilizar información personal sin ningún 
problema de seguridad. 


D. Patrones de ataque y de mal uso 


En este apartado se incluyen los trabajos que describen otro 
tipo de patrones de seguridad: los patrones de ataque y los 
patrones de mal uso. En este tipo de patrones los autores se 
colocan en el lado del atacante y describen paso a paso todos 
los elementos del ataque a un sistema. Para ello definen el 
contexto del ataque, exponen los patrones de seguridad que lo 
neutralizan y proponen mecanismos para trazar las evidencias 
que deja el ataque una vez que ha ocurrido. 

En [16] se propone un patrón de uso indebido y se presenta 
un modelo que expone la estructura de este tipo de patrón. 
De manera similar al anterior trabajo, en [31] se presenta un 
patrón de ataque, que proporciona una descripción específica 
de los objetivos del ataque. Además, se presenta como ejemplo 
ficticio un ataque de denegación de servicio en las redes de 
tipo VoIP para demostrar la efectividad del patrón expuesto. 


E. Patrones de seguridad para mejorar la relación de confi- 
anza 


En este apartado se incluyen los trabajos que proponen 
patrones de seguridad para reforzar las relaciones de confianza 
entre el usuario y los sistemas o entre dos usuarios, para tratar 
de cumplir los requisitos fundamentales de seguridad. 

En [32] se presenta un patrón de seguridad para desarrollar 
una interfaz gráfica de usuario segura. Este patrón puede 
ayudar a reforzar los sistemas de interfaz gráfica de usuario 
y evaluar su uso en diferentes ámbitos. Además, se muestra 
cómo analizar los requisitos de seguridad para fomentar la 
confianza, preservando al mismo tiempo la flexibilidad que 
demandan las interfaces gráficas de usuario. 

En [33] se describen patrones para reforzar las relaciones 
de confianza entre diferentes usuarios. Estos patrones permiten 
que dos usuarios puedan verificar mutuamente el perfil del otro 
sin revelar su identidad. 


FE. Otros patrones de seguridad para construir sistemas se- 
guros 


En este apartado se muestran varias propuestas para cons- 
truir sistemas seguros utilizando patrones de seguridad, tanto 
de diseño como arquitectónicos. 

En [34] se propone un patrón para reforzar las arquitecturas 
basadas en tres capas. Este patrón puede ser aplicado a 
sistemas distribuidos y enfocado a la ejecución de aplicaciones 
complejas y heterogéneas. Hay distintos debates sobre las 
propiedades del patrón arquitectónico en tres capas, así como 


varios patrones desarrollados [35, 36], pero ninguno de éstos 
considera la seguridad. 

En [37] se describen patrones de seguridad para la re- 
presentación de los procesos y subprocesos de los sistemas 
operativos. Como los sistemas operativos son muy críticos, los 
autores proponen varios patrones para resolver sus problemas 
de seguridad. 

En [38] se introducen patrones para monitorizar las 
propiedades de seguridad básicas de un SI. Con ellos se 
puede comprobar, en tiempo de ejecución, la robustez de los 
requisitos generales de seguridad de un SL. 


III. RESULTADOS Y DISCUSIÓN 


Como se ha mostrado en la sección anterior, existe una 
gran variedad de propuestas que trabajan descubriendo nuevos 
patrones de seguridad en relación a las necesidades de los SI. 
En esta sección se van a analizar, por un lado, los criterios 
de descripción utilizados en las propuestas sintetizadas y por 
otro lado, los entornos en los que son aplicados los patrones 
descritos. Finalmente, se mostrará una discusión en relación a 
los resultados obtenidos y se propondrán una serie de mejoras. 

En la Figura 1 se muestran horizontalmente las referencias 
de los trabajos sintetizados y el contexto al que pertenece 
cada uno de ellos, siguiendo la estructura de los apartados 
descritos en la sección anterior. Verticalmente se muestran las 
plantillas que han sido utilizadas para describir las propuestas, 
detallando los elementos utilizados en la descripción de cada 
uno de los patrones de seguridad. Las plantillas de descripción 
incluidas en la Figura 1 son, la plantilla resultante de la fusión 
de elementos de la plantilla propuesta por Gang of Four [39] 
adaptada a los patrones de seguridad y de la plantilla propuesta 
por Buschmann et al. [40] denominada PoSA, la plantilla 
propuesta en el proyecto SERENITY utilizada en [26], la 
plantilla propuesta por Alexander [3], y la plantilla de des- 
cripción de patrones en forma de eventos de cálculo [38]. Se 
sombrearán las casillas que correspondan a las plantillas o ele- 
mentos de descripción que utilicen cada una de las propuestas 
respectivamente. Como se puede extraer de la Figura 1 y más 
concretamente de las columnas que representan las plantillas 
utilizadas en la descripción de patrones, no existe una plantilla 
estándar que sirva de guía para la descripción de patrones 
de seguridad que pueda ser utilizada por los expertos en esta 
materia. Esta situación provoca una variabilidad significativa 
en relación a los elementos que componen un patrón de 
seguridad. Como se observa en las columnas que se refieren a 
los elementos utilizados en las descripciones de patrones, cada 
autor describe los patrones siguiendo sus propias directrices, 
aunque existen algunos elementos comunes de las diferentes 
plantillas [18, 26, 30]. Incluso utilizando la misma plantilla, 
algunos autores no repiten en su totalidad todos los elementos 
de ésta, probablemente fruto de evolución en sus propuestas 
y tratando de mejorar la usabilidad de los patrones, optan por 
añadir nuevos elementos [25, 27, 29]. 

Los elementos más utilizados en las descripciones de pa- 
trones de seguridad son la tripleta Contexto”, Problema” 
y ”Solución” propuesta en [3]. Esto demuestra que existe 
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Fig. 1. 


una necesidad por parte de los investigadores de definir una 
serie de conceptos básicos a la hora de documentar un patrón 
descubierto, pero al carecer de una plantilla estándar para 
exponer los patrones de seguridad, se genera una diversidad 
muy destacada en las distintas descripciones. Debido a esta 
diversidad aumenta la complejidad para realizar un catálogo 
homogéneo de patrones de seguridad, ya que es difícil unificar 
toda la literatura existente sobre éstos. Este hecho también 
puede provocar que los diseñadores de SI tengan cada vez más 
dificultad a la hora de seleccionar los patrones más apropiados 
para unos determinados requisitos de seguridad dados [41]. 
Localizado este problema se detecta la necesidad de diseñar 
un conjunto de pautas que recojan una serie de características 
esenciales para la descripción de los patrones de seguridad, 
con el fin de conseguir un catálogo homogéneo. La principal 
aportación de este catálogo sería conseguir soluciones equiva- 
lentes entre distintos diseñadores de SI seguros. 


Adicionalmente al análisis realizado sobre las distintas 
descripciones utilizadas en el diseño de patrones de seguridad, 
se ha realizado un análisis sobre los entornos en los que 
son validadas las propuestas seleccionadas. En la Figura 2 
se muestran los porcentajes de las propuestas que han sido 
validadas en entornos reales (SI), las que han sido validadas 
parcialmente en entornos reales (PARCIALMENTE), es decir, 
han simulado un entorno real a pequeña escala y las que 
están basadas en casos de laboratorio (NO). Como se puede 


Características de las propuestas estudiadas 


observar en la Figura 2, el 59% de las propuestas seleccionadas 
están basadas en ejemplos teóricos o casos de laboratorio, el 
29% de ellas están validadas en un entorno real simulado, 
mientras que sólo el 12% de las propuestas han sido validadas 
completamente en entornos reales. 


Fig. 2. 


Propuestas validadas en entornos reales 


Tras realizar este análisis se detecta una carencia de visión 
real en los patrones de seguridad, es decir, no se expone 
una aproximación práctica específica para el diseño de SI 
seguros basado en patrones de seguridad. Este aspecto di- 
fiere en su totalidad de la propia definición de patrón, que 
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precisamente declara que una de las principales bondades de 
los patrones es que proporcionan soluciones validadas que 
resuelven problemas similares. Este hecho puede provocar una 
escasa aplicabilidad de los patrones de seguridad en diseños de 
SI reales, ya que probablemente éstos no han sido generados 
cómo conclusión de la solución a un problema en un entorno 
real complejo. 

Un patrón de seguridad debería servir para simplificar la 
toma de decisiones de un ingeniero de seguridad de la infor- 
mación a la hora de diseñar un nuevo SI o implantar un nuevo 
sistema dentro de un sistema mayor, reduciendo el tiempo y 
el coste del análisis de seguridad. Desde nuestra experiencia, 
a la hora de realizar el análisis de seguridad de un SI en un 
entorno real es necesario considerar los aspectos relativos a: 
a) el número de elementos físicos y lógicos que componen 
el SI, b) la gestión y aprovisionamiento de usuarios; c) el 
proceso de copias de seguridad y sobre qué elementos habría 
que realizarlas; d) la trazabilidad de la solución aportada; e) 
la expansión de la solución de forma masiva; f) el impacto 
en los parámetros básicos de un SL, la memoria, la capacidad 
de proceso, el almacenamiento, el ancho de banda consumido, 
etc. Por todo esto, los patrones de seguridad basados en casos 
de laboratorio difícilmente pueden ser utilizados en un proceso 
de diseño de un SI real, ya que la mayoría no tienen en cuenta 
la complejidad de las instalaciones reales incumpliendo las 
premisas anteriores cuando son diseñados. En caso de ser 
utilizados por un ingeniero de Sl, existe la posibilidad que 
aumente el tiempo y el coste del análisis de seguridad en el 
ciclo de vida del diseño del SL. 

Para concluir este apartado se van a exponer las necesidades 
detectadas tras el análisis realizado. En primer lugar, hay 
que destacar la complejidad que presenta ofrecer actualmente, 
tanto al experto como al no experto en seguridad, una guía de 
soluciones reutilizables, a fin de que sea usada para diseñar un 
sistema seguro, ya que como queda demostrado, no es tarea 
fácil alinear los diferentes criterios de descripción en el ámbito 
de los patrones de seguridad. Por este motivo, se detecta la 
necesidad de establecer una metodología dentro del ámbito 
de la Seguridad de la Información en la que paso a paso, 
se describa cómo resolver un problema utilizando patrones 
de seguridad. Esta metodología debería aportar soluciones 
equivalentes entre distintos diseñadores de SI, con el fin de 
que esas soluciones puedan ser utilizadas por cualquiera que 
lo necesite, beneficiándose sin necesidad de tener conocimien- 
tos avanzados en el campo de la seguridad. Las soluciones 
aportadas llegarían a ser reutilizables y exportables, ya que 
recogerían todas las características técnicas del sistema, las 
personas involucradas en la solución planteada, etc. Además, 
se detecta una clara necesidad de crear soluciones de seguridad 
estructuradas en forma de patrones que reflejen soluciones 
validadas en entornos reales complejos siguiendo las premisas 
que se han expuesto anteriormente. Finalmente, se detecta la 
necesidad de enriquecer y completar la descripción de los 
patrones de seguridad actuales, con un conjunto de elementos 
que describan los aspectos principales para un diseñador de SI 
a la hora de implementar la solución en instalaciones reales, 


con el fin de aumentar la aplicabilidad de estos patrones ya 
descubiertos en este tipo de entornos. 


TV. CONCLUSIONES Y TRABAJOS FUTUROS 


En este trabajo se han sintetizado un conjunto de propuestas 
que describen patrones de seguridad. Se puede observar que 
el número de estudios dentro de este ámbito es muy elevado 
y abarca distintos contextos, encontrando gran heterogeneidad 
en el proceso de creación de patrones descrito por los distintos 
investigadores. Cada uno de los enfoques selecciona un con- 
junto distinto de elementos para realizar la descripción de los 
patrones, provocando un aumento de complejidad al realizar 
una clasificación homogénea de los patrones existentes. Por 
este motivo, los diseñadores de los SI pueden tener una 
mayor dificultad a la hora de seleccionar una serie de patrones 
apropiados para diseñar sus sistemas seguros. Por todo esto, se 
cree necesario definir un conjunto de pautas de descripción de 
patrones de seguridad que sea aceptado y utilizado por todos 
los investigadores relacionados con este campo. 

Partiendo de la base de que los patrones por definición son 
un mecanismo validado, en la realización del estudio se han 
encontrado muy pocas propuestas validadas en entornos reales 
complejos. Por nuestra experiencia, los patrones de seguridad 
deberían considerar aspectos tales como medidas volumétricas 
de los parámetros básicos de un SI (memoria, capacidad de 
proceso, almacenamiento, etc.), gestión de usuarios, medidas 
de complejidad de uso, tanto para administradores como para 
usuarios finales, etc. En la actualidad, los patrones existentes 
no contemplan estos aspectos, por lo que se propone una 
profunda investigación para descubrir nuevos patrones que sí 
los reflejen. Además, se considera necesaria una evolución de 
los patrones existentes para cubrir las necesidades anteriores. 
Por último, se propone el desarrollo de una metodología de 
seguridad basada en patrones que guie al usuario a la hora 
de afrontar un problema en este ámbito. Esta metodología 
debería ser útil para cualquier tipo de diseñador de sistemas 
de seguridad, ya sea experto o no en este ámbito. 

En trabajos futuros, se pretende abordar el desarrollo de 
una serie de pautas que recojan un conjunto de características 
principales para la definición de nuevos patrones de seguridad, 
con el fin de mantener un criterio equivalente entre las distintas 
propuestas que se vayan realizando. También, se pretende des- 
cubrir nuevos patrones de seguridad que cumplan los requisitos 
expuestos para aplicarlos en entornos reales. Finalmente, se 
propondrá una metodología de seguridad basada en patrones 
que aporte soluciones homólogas, validadas y reutilizables. 
Esta metodología servirá para dar soporte a los diseñadores 
de SI seguros para que paso a paso sepan cómo afrontar un 
problema de seguridad guiándoles para que lo resuelvan de la 
manera más óptima y eficiente posible. 
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Abstracit—Las firmas de seguridad y especialmente los fab- 
ricantes de Antivirus dan fe del aumento exponencial de las 
amenazas que acechan las actividades realizadas en Internet [1], 
habiendo analizado más ejemplares de malware en el 2009 que en 
la suma de todos los años anteriores. Se constata que fabricantes 
de virus, gusanos, troyanos, spyware, spam etc. no realizan sus 
actividades maliciosas de forma aislada, sino que se trata de 
bandas organizadas y consolidadas [2] que buscan obtener un 
beneficio económico a través de sus acciones ilícitas. 

En este trabajo se presenta Euskalert, una infraestructura de 
máquinas trampa que recopila ataques a nivel de red y malware. 


I. INTRODUCCIÓN 


A lo largo de los últimos 3 años desde la Escuela Politécnica 
Superior de Mondragon Unibertsitatea, en adelante MU, se 
ha trabajado en el proyecto Euskalert [3]. Se ha implantado 
una red de honeypots en la Comunidad Autónoma del País 
Vasco (CAPV). Los participantes alojan un sensor en su red 
corporativa y los datos sobre los ataques son recibidos y 
almacenados en nuestras instalaciones, todo ello de forma 
eficiente y segura. Los participantes tienen a su disposición un 
sitio Web donde pueden consultar libremente información y es- 
tadísticas sobre los ataques recibidos, así como compararse con 
otros participantes de forma anónima. Una vez la plataforma 
se encuentra estable y con cierta capacidad de análisis, las 
posibilidades en cuanto a la explotación de la información 
tanto a nivel de red como de aplicación se multiplican. 

El malware es cualquier tipo de código diseñado es- 
pecíficamente con intención dañina, como por ejemplo virus, 
gusanos, caballos de troya o spyware. Debido al exponen- 
cial aumento del malware, y por consiguiente el benefi- 
cio económico que ciberdelincuentes obtienen mediante su 
uso [4], [5], el estudio, análisis y mitigación representa una 
necesidad prioritaria para investigadores y gobiernos. 

En la actualidad, la solución principal para luchar contra 
el malware recae en los sistemas antivirus, basados mayori- 
tariamente en firmas sintácticas, que caracterizan instancias 
conocidas de malware mediante firmas. Las firmas representan 
el o los bytes específicos o secuencias de instrucciones que 
se consideran maliciosas. Cuando al escanear un fichero se 
identifica este patrón, es clasificado como malware. Este 
método ha resultado efectivo hasta el momento, cuando las 
amenazas son conocidas de antemano y es la solución más 
extendida en el software antivirus. 

El sistema Euskalert resulta muy beneficioso para obtener 
nuevas instancias de malware para ser analizadas. De todos 
modos, el método tradicional de analizar el malware implica 


que un analista deba realizar ciertos tests y extraer la infor- 
mación significativa para clasificar la muestra y desarrollar una 
firma específica [6]. Con el incremento percibido del número 
de código malicioso detectado, más de 37.000 nuevas vari- 
antes de malware al día según Panda Security, las compañías 
antivirus reciben miles de ficheros sospechosos que deben ser 
analizados y clasificados como software benigno, o al contrario 
malware. Por esta razón, la automatización de algunas de estas 
tareas de análisis y clasificación en un tiempo corto es un punto 
importante a tratar. 


II. ESTADO DEL ARTE 
A. Honeypots o Máquinas Trampa 


Un sistema trampa es un recurso de seguridad informática 
cuyo valor reside en ser explorado, atacado o puesto en 
compromiso [7]. Un sistema trampa no tiene ninguna función 
autorizada ni ningún valor productivo dentro de una red 
corporativa. Por tanto, un sistema trampa no debería recibir 
ningún tipo de tráfico. Cualquier intento de conexión con un 
sistema trampa es, con total seguridad, una exploración, un 
ataque o un intento de comprometer la máquina o el servicio 
que está ofreciendo [8]. Cuanto más conozcamos cómo actúan 
los atacantes, sus métodos y las herramientas que utilizan, 
mejor podremos protegernos. 

Los sistemas trampa pueden clasificarse en función de 
varios aspectos. Por un lado, según su objetivo se pueden 
diferenciar entre sistemas trampa con sentido productivo (para 
prevención y ayuda en la respuesta en redes corporativas) y 
aquellos dedicados a la investigación (con el fin de recopilar 
información y analizarla para aprender métodos utilizados por 
los atacantes). Por otro lado, una de las clasificaciones más 
extendidas en torno a los sistemas trampa es la que hace 
referencia a su nivel de interacción. Los sistemas trampa de 
baja interacción ofrecen una baja y limitada interactividad 
hacia los atacantes. La mayoría de los desarrollos e imple- 
mentaciones de sistemas trampa de baja interacción, no son 
más que simuladores de servicios y de sistemas operativos. 
Ejemplos de este tipo de sistemas trampa son Honeyd [9], 
LaBrea [10] o Honeytrap [11]. En los sistemas trampa de 
alta interacción la estrategia es distinta. No se simula nada, 
sino que se trabaja con sistemas operativos y aplicaciones 
reales, generalmente ejecutandose en máquinas virtuales. En 
este apartado se encuentran Argos [12], Minos [13], y algunos 
proyectos de la Honeynet Research Alliance [14]. También 
se podrían encontrar sistemas trampa reconocidos como de 
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media interacción, que también emulan servicios vulnerables, 
pero además dejan al propio sistema operativo gestionar las 
conexiones mediante sus protocolos y pila de red reales. 
Entre este tipo de máquinas trampa podríamos clasificar a 
BillyGoat [15], Nepenthes [16] o Amun Honyepot [17]. Este 
es el tipo de máquina trampa utilizado por los investigadores 
de este proyecto, por su experiencia en el desarrollo de Billy 
Goat (Ziirich IBM Research Laboratory), y porque cumple con 
los requisitos necesarios ya que son capaces de gestionar la 
conexión llegando incluso a descargar el malware. 

Por otro lado, recientemente se han propuesto otro tipo 
de máquinas trampa, como resultado del cambio de estrate- 
gla que se ha observado por parte de los atacantes. Los 
ciberdelincuentes ya no hacen uso únicamente de la capa de 
red para propagar el malware, sino que han sabido explotar 
vulnerabilidades dirigidas a aplicaciones cliente como naveg- 
adores web, pdf, jpeg, etc. Dándoles la capacidad de ejecutar 
código arbitrario en el lado del usuario. De este modo, en 
lugar de esperar de forma pasiva a que los ataques lleguen 
a máquinas trampa tradicionales o del lado de servidor, se 
han desarrollado máquinas trampa del lado de cliente, también 
conocidos como Honeyclients. Su función es la de rastrear un 
canal de comunicación, como la Web, en busca de malware. 
Un Honeyclient es un equipo dedicado que maneja aplica- 
ciones específicamente instrumentadas para acceder a servi- 
dores remotos y comprobar si dichos servidores se comportan 
de manera maliciosa. Específicamente, estos sistemas pueden 
detectar proactivamente exploits contra las aplicaciones sin 
necesidad de firmas conocidas. Pueden hacerlo de forma 
automatizada, o mediante una lista de URLs que se añade 
manualmente o a partir de otros sistemas (links en correo 
spam, ...). Los ejemplos más conocidos de Honeyclients son 
Honeymonkey [18], MonkeySpider [19], o Capture HPC [20]. 


B. Infraestructuras de Máquinas Trampa Existentes para la 
Colección de Datos 


La monitorización de tráfico no solicitado ha demostrado ser 
una técnica eficiente para la detección de amenazas en Internet 
y colección de malware. En estos últimos años, se han pro- 
puesto dos sistemas de monitorización apropiados para realizar 
dicha función: los sistemas trampa y los monitores de red. 
Ambos sistemas monitorizan direccionamiento IP no asignado 
de modo que cada vez que recibe una petición de conexión, 
ésta será considerada como sospechosa. No obstante, el nivel 
de interacción de estos sistemas es fundamental. 

Los primeros monitores de tráfico de Internet, conocidos 
como Network Telescopes, Black Hole Monitors o Internet 
Sinks se presentan en [21]. Utilizan grandes rangos de di- 
reccionamiento IP no asignados para la recolección de infor- 
mación proveniente en su mayoría de gusanos informáticos 
tratando de propagarse, así como de fallos de configuración en 
equipamiento de red. Los principales Telescopios de Red son, 
entre otros, UCSD Network Telescope de la Universidad de 
California en San Diego [22] e IMS (Internet Motion Sensor) 
de la Universidad de Michigan [23]. 


Por otro lado, Existen también redes colaborativas formadas 
por máquinas trampa distribuidas que tratan de ocupar mayor 
espectro de red para obtener una vista más amplia de lo 
que sucede en Internet (Leurré.com/SGNET [24], NoAH [23], 
SURFids [26], Honeynet Project Alliance [14], o la Red Vasca 
de Honeypots, Euskalert [3]). 


C. Técnicas de Análisis de Malware 


Hasta el momento se han propuesto dos enfoques para el 
análisis de malware: análisis estático [27], [28] y análisis 
dinámico [29], [30], [31], [34], [35], [36], [37], [38], [39]. 


El análisis estático se realiza sin ejecutar el código mali- 
cioso, observando el código fuente o los binarios en busca 
de patrones sospechosos. A pesar de que algunos enfoques 
han obtenido buenos resultados, los autores de malware han 
desarrollado diferentes técnicas de ofuscación [32], como 
polimorfismo o cifrado, que son especialmente eficaces contra 
el análisis estático, tal como se presenta en el trabajo re- 
ciente [33], donde se demuestra un método para la ofuscación 
mediante una técnica llamada Opaque Constants. 


Por otro lado, el análisis dinámico o de comportamiento [34] 
implica ejecutar la muestra en un entorno aislado y controlado, 
conocido como sandbox, para realizar un seguimiento de 
su comportamiento. Existen diferentes soluciones basadas en 
sandbox-es, utilizando técnicas para supervisar el compor- 
tamiento del malware: TTAnalyze [35] y Anubis [36] utiliza 
el emulador de PC Qemu para cargar un sistema operativo 
Windows combinado con una técnica conocida como enganche 
o hooking de la API. Por otra parte, CWSandbox [37] se basa 
también en un hooking de la API y la inyección de librerías 
DLL para rastrear y monitorizar todas las llamadas al sis- 
tema, y generar un informe. Norman Sanbox [38] simula una 
computadora completa reimplementando un sistema Windows 
básico. Finalmente, Wepawet [39] es un sistema de análisis 
dinámico de ficheros Javascript, Flash y PDF maliciosos. 


En cuanto a los trabajos de clasificación automática de 
malware, se han propuesto diferentes técnicas. Si nos fijamos 
en los algoritmos de minería de datos utilizados, observamos 
trabajos que utilizan árboles de decisión [40], máquinas de 
soporte vectorial [31], y algoritmos bayesianos [41]. En cuanto 
al objetivo perseguido por estos trabajos, podemos diferenciar 
aquellos que pretenden clasificar familias de malware me- 
diante el agrupamiento de características extraídas a partir de 
informes de comportamiento de malware [42]. En los mismos, 
se transforman los informes obtenidos del sandbox en secuen- 
cias de características, agrupando estas más tarde mediante 
técnicas de clustering. Esta solución tiene ciertas limitaciones, 
debido a la naturaleza no supervisada del clustering, con sus 
problemas inherentes. En otro enfoque perseguido, se trata de 
discriminar entre el software malicioso y el benigno, basado 
en la extracción de características estáticas del malware [43], 
o de comportamiento tanto de programas maliciosos como 
benignos [44]. 
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IP Honeypot 2 


TII. EUSKALERT: RED VASCA DE HONEYPOTS 


Euskalert es una red distribuida de honeypots basada en 
Honeynet Genlll [14]. La arquitectura desarrollada en Eus- 
kalert es la siguiente: 


Interfaces sin IP 
Modo enlace de red 


SERVIDOR 


IP Sensor 1 
IP Honeypot 1 


IP Honeypot 2 


Repositorio, IP Honeypot n 


de datos /) 


IP Sensor 2 


=l 
AH 


E SS LS 
Úúnel Ethernet encriptado 
sobre TCPAP 


Monitorización y túnel en la 
misma interfaz de red con IP 
pública 


LAN 
IP Sensor n (ADMINISTRACIÓN) 


IP Honeypot n 


HONEYCLIENT 


Fig. 1. Arquitectura de Euskalert, la Red Vasca de Honeypots 


Como se puede observar, a la izquierda de la Figura 1 se 
encuentran los diferentes sensores instalados en las redes cor- 
porativas de los diferentes participantes. Cada sensor tiene per- 
manentemente establecida una conexión encriptada (mediante 
diferentes redes privadas virtuales, también conocidas como 
VPNs) con un servidor de túneles. Éste último se encuentra 
en la DMZ de MU. Todo ataque o intento de propagación de 
ataque a los sensores son redirigidos a través de estos túneles 
hasta llegar al honeypot (derecha de la Figura), quien es el 
responsable de responder a todo intento de conexión. El tráfico 
también atraviesa un servidor encargado de recopilar toda la 
información que luego será mostrada en la plataforma Web 
http://www.euskalert.net. 

Los elementos que componen la arquitectura son: 


. Sensores: Pequeños dispositivos de bajo coste (Linksys 
NSLUZ2), cuyo firmware ha sido modificado para alber- 
gar un Sistema Operativo GNU/Linux con los servicios 
necesarios utilizando un dispositivo de almacenamiento 
externo USB. El software incluye Honeymole Client (The 
Honeynet Project), SNMP para su monitorización, el 
Firewall IPTables para su protección, SSH para la gestión 
y OpenSSL para crear un túnel cifrado con el Servidor 
de Túneles. 

. Servidor de Túneles: Esta máquina es una distribución 
completa de GNU/Linux sobre la que se instala Ho- 
neymole Server (The Honeynet Project). Su principal 
cometido es el de crear túneles Ethernet encriptados 
(puede manejar varios simultáneamente) a partir de las 
peticiones hechas por los sensores Euskalert y redirigir 
hacia el Honeywall y honeypot las tramas encapsuladas 
en dichos túneles, así como remitir a los sensores las 
respuestas de esas conexiones. Los túneles son creados 
sobre la interfaz de red pública y los reenvíos de las 
tramas que por éstos llegan se realizan hacia el segmento 
de la interfaz interna. 


+ Honeywall: El Honeywall es un host que funciona como 
pasarela de nivel 2, uniendo el segmento de red del 
honeypot con el del servidor de túneles. Todo el tráfico 
que los sensores Euskalert envían al servidor de túneles 
es redirigido por este último hacia el Honeywall, posi- 
bilitándole monitorizar y registrar todos los flujos que 
lo atraviesan. Lleva instalado software para captura de 
información: Snort IDS, IPTables, Argus, p0Of y Tepdump, 
además de herramientas desarrolladas por MU para la ex- 
tracción automática de información de origen geográfico 
y secuencias de puertos atacados. 

+. Honeypot: El honeypot es uno de los puntos más impor- 
tantes de la infraestructura Euskalert porque representa 
la víctima hacia la que atacantes, gusanos y virus lanzan 
sus ataques. El componente software que emula máquinas 
y servicios se denomina honeypot, nombre que por ex- 
tensión también toma el propio equipo. Euskalert hace 
uso del honeypot amun [17], especialmente indicado para 
la detección y captura de gusanos y malware en general. 
Como complemento suyo también se ejecuta Honeytrap, 
un manejador de conexiones establecidas contra puertos 
de servicios no emulados por Amun. La combinación de 
ambos proporciona la monitorización de todo el rango 
de puertos y la captura de la información enviada en las 
sesiones efectuadas contra ellos. 

. HoneyClient: Se trata de una máquina trampa del lado de 
cliente con capacidad de rastrear URLs en busca de soft- 
ware malicioso alojado en Servidores de Internet. Puede 
hacer búsquedas automáticas (implica mucha carga de 
trabajo y poco malware), o a partir de listas predefinidas 
de URLs. 


TV. RESULTADOS 


Euskalert recopila aproximadamente una media de 4000 pa- 
quetes maliciosos al mes. La Figura 2 muestra su distribución 
en el mes de Marzo del 2010. En la misma, se incluye (en la 
línea de puntos) el número de malware que ha sido descargado 
en el mismo periodo, que no supera los 6 ejemplares por día: 
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Fig. 2. Distribución diaria de ataques a la plataforma Euskalert 
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En cuanto al contenido del tráfico, la tabla 1 muestra los 
servicios más atacados en la misma muestra anterior: 


Puerto Destino | N. Paquetes | Descripción 
445 2091 Microsoft-DS compartición de ficheros 
8 412 ICMP echo 
5061 217 Inicio de sesión sobre TLS 
135 202 DCE endpoint resolution de Microsoft 
22 197 ssh, Secure Shell 
139 152 NetBIOS Servicio de sesiones 
80 139 HTTP 
443 135 Protocolo HTTP sobre TLS/SSL 
1433 76 Microsoft-SQL-Server 
1521 76 Servidor de Base de Datos Oracle 
TABLE I 


SERVICIOS (PUERTOS) MÁS ATACADOS 


Algunos resultados, como la geolocalización de los ata- 
cantes, los ataques detectados por el IDS Snort, y los servicios 
y protocolos atacados se publican de forma automática en la 
dirección http://www.euskalert.net, tal y como se muestra en 
la Figura 3. 


GET /twiki/bin/statistics HTTP/1.1 Accept: */x* 
Accept-Language: en-us Accept-Encoding: gzip, 

deflate User-Agent: Toata dragostea mea pentru 
diavola Host: *x*x*,x*xx*x.xx*xx*.49 Connection: Close 


OPTIONS / HTTP/1.1 translate: f User-Agent: 
Microsoft-WebDAV-MiniRedir/5.1.2600 Host: 

XX .***.***x.61 Content-Length: 0 Connection: 
Keep-Alive 


GET /roundcube/program/3]s/list.js HTTP/1.1 Accept: 
*/x* Accept-Language:en-us Accept-Encoding: gzip, 
deflate User-Agent: Toata dragostea mea pentru 
diavola Host: x*x*.**x*.**x*x.49 Connection: Close 


GET/unauthenticated/..%01/..%01/..%01/..%01/..%01/ 
.201/..%01/..%01/etc/passwd HTTP/1.1 

Accept: */* Accept-Language: en-us Accept-Encoding: 

gzip, deflateUser-Agent: Toata dragostea mea pentru 

diavola Host: x*x*.*x**.**x*.49Connection: Close 


POST /webmail/bin/html2text.phep HTTP/1.0 Host: 
**k.***.**x*.69 User-Agent:Mozilla/4.0 (compatible; 
MSIE 7.0; Windows NT 5.1; InfoPath.2) 
Content-length: 54 

Accept : ZWNobygiU3VjY2V1ZGVKkISA6KS1cclxuXHJcbi4iKTsK 
<b>($(EVAL (BASE64_DECODE ($_SERVER[HTTP_ACCEPT])))) 
</b> 


Fig. 3. Interfaz web de la plataforma Euskalert 


Fig. 5. Ataques / pruebas vía HTTP 


V. CONCLUSIONES Y PRÓXIMOS PASOS 


El objetivo prioritario de Euskalert es el de mantener una 


red de máquinas trampa (de distinta índole) que sirva como 
observatorio de activad maliciosa en la red. Esto permite 
disponer de un sistema de alerta temprana para empresas e 
instituciones y de un almacén centralizado de ataques para 
utilizar en proyectos de investigación científica en el área de 
la seguridad telemática. El sistema actual se encuentra estable 
y recopila ataques de distintos tipos, así como malware de 
forma automática. El siguiente paso lógico será el de analizar 
los ataques que llegan y así aprender de nuevas tendencias, 


técnicas etc. de los atacantes, para poder investigar métodos 
para su defensa. 


En cuanto a ataques específicos, a modo de ejemplo se 


Para completar el sistema actual, se plantean los siguientes 


muestran por un lado intentos de acceso a nivel FTP, y por Pasos: 


el otro intentos de ataques automáticos vía HTTP a diferentes 
aplicaciones Web conocidas: 


RMD sarcaxxo 

PASS 

USER administrator 
PASS NULL 

MKD 090713182104p 

CWD /public/ 

PASS Pgpuserfthome.com 
USER anonymous 

PASS ftpltexample.com 
PWD EPSV 


Fig. 4. Intentos de acceso vía FTP 
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+ Obtener mayor volumen de datos aumentando el número 
de sensores de la red distribuida de máquinas trampa. 

+. Desarrollar un método para la investigación de amenazas 
en entornos Web 2.0, automatizando servicios como la 
Mensajería Instantánea (Instant Messaging) y como la 
herramienta Twitter. 

+. Desarrollar un método para emular aplicaciones Web y 
así recoger ataques (Cross Site Scripting, SQL Injec- 
tion,..) dirigidos a aplicaciones específicas de http. 

+ Establecer y desarrollar una metodología de minería de 
datos para identificar de forma automática el malware 
recibido por el sistema, utilizando información de análisis 
estático y dinámico del malware, proporcionado por las 
empresas colaboradoras. 


+. Diseñar y desarrollar un sistema Business Intelligence e 
integrarlo en el sitio Web de Euskalert. 
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Abstract—Main goal of biometric systems relies on avoiding in- 
trusion acceptance. However, most extended biometric techniques 
lack of skills when providing information on individual intentions. 
Most intrusions imply an arousal in the human physiological 
response, better known as stress response. Therefore, stress 
detection is strongly related to intrusion detection. This paper 
attempts to provide a stress detection scheme based on Gaussian 
Mixture Models, elucidating to what extend an individual is 
under stress. Furthermore, results come up to stress detection 
rates of 96.2+0.2% and non-stress detection rates of 86.5+0.5%, 
which means that the system can detect properly the degree of 
stress on an individual with competitive results if compared to 
the literature. 


I. INTRODUCTION 


Intrusion detection attempts to identify malicious behavior 
of a certain user within a network or system [1]. More in 
detail, Intrusion Detection and Prevention Systems (IDPS) 
focus on detecting and identifying incidents, logging any 
related information and avoiding conflictive and insecure sit- 
uations. Several approaches have been already proposed in 
the literature providing different strategies to tackle with this 
problem. For instance, Fast Inductive Learning [2], Support 
Vector Machine [3] or Neural Networks [4] among others [5], 
[6] provide good results in intrusion detection. 

Besides, biometrics have become recently into an impor- 
tant topic of interest in relation to intrusion detection, since 
biometric techniques allow to identify/authenticate a user 
in a precise manner, and therefore, ensuring the fact that 
associating actions to individuals may increase the detection 
of intrusive activities [7], [8]. These biometric techniques are 
based concretely on behavioral biometrics [9], [10], assuming 
that a certain user usually behaves in the same manner in a 
system. Any uncommon behavior would indicate a possible 
intrusive and malicious activity. 

Regarding biometrics, this paper proposes to elucidate in- 
trusive behaviors by means of stress detection. This approach 
implies to detect the arousal emotions of an individual, or more 
specifically, the human stress response. Stress detection is 
known to provide real-time information on the emotional state- 
of-mind of an individual with almost non-invasive acquisition 
devices [11], [12], being a very suitable technique for intrusion 
detection. Stress detection exceeds previous biometric ap- 
proaches based on two reasons: firstly, stress detection is more 
related to human intentions than behavioral biometrics [13], 


[14]; secondly, stress detection is a reliable and trustworthy 
technique, since the human stress response cannot be forced 
or disguised, in the same way an individual cannot stop his/her 
heart by his/her own [15], [16], [17]. 

The relation between stress and malicious actions is obvi- 
ous: high levels of stress indicates uncommon or abnormals 
situations in where an individual could pretend commit a ma- 
licious actions, or the environment is affecting the individual 
(a robbery, for instance). 

However, how is it possible to measure human stress? Most 
common approaches in stress detection consider physiological 
signals [18] as the most suitable bio-marker in terms of stress 
arousal. This paper focuses on two specific physiological 
signals, namely Galvanic Skin Response (GSR) [19], [20] and 
Heart Rate (HR) [21], [15]. Furthermore, this paper proposes 
the use of Gaussian Mixture Models (GMM) [22], as a proper 
method to deal with the information provided by previous 
physiological signals. 

Moreover, its simplicity and non-invasiveness make of this 
approach a suitable scheme to be easily embedded in general 
current accessing systems. 

Results direct attention towards the fact that stress detection 
can be implemented for real-time applications with a high 
performance. 

The layout of this paper is as follows: Section II presents 
how the database was acquired to validate the algorithms, 
stating the mathematical model of the algorithm in Section 
TIT. Results will be provided under Section IV, yielding to the 
Conclusions and Future Work presented in Section V. 


Il. DATA ACQUISITION 


Acquiring precise data is one of the main problems of stress 
detection. A database to validate the implemented algorithms 
must include two states: a relax and a stress state, in order 
to compare to what extend the system is able to distinguish 
between a stressing and a normal situation, or in other words, 
between and intrusive or a non-intrusive scene. Since the stress 
arousal cannot be controlled by an individual [15], [16], then 
the stress stimuli must be induced and provoked. Thus, a 
experimental setup was carried out in order to arise stress 
on individuals, based on two stressing tasks: Hyperventilation 
(HV) and Talk Preparation (TP), [23], [24], which have been 
extensively used to provoke stress on individuals with very 
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satisfactory results. Firstly, HV represents a kind of breath, 
exceeding standard metabolic demands. Secondly, TP is a very 
anxiogenic task which ensures a positive valence in terms 
of stress response. Furthermore, despite of provoking similar 
responses on humans, HV does not produce a significant in- 
crement in anxiety intensity, and therefore, a more anxiogenic 
task, TP, is required. 

These experiments were carried out in a Faraday room in 
the Human Psychology Laboratory from Psychology Faculty 
of Complutense University of Madrid (UCM), provided with 
electromagnetic, thermal and acoustic insulation. As previ- 
ously stated, HR and GSR are collected during the experiments 
from each participant, having sensors attached to wrists, fin- 
gers and ankles of the individual [25]. The device proposed 
1s 1-330-C2 PHYSIOLAB (J 83 Engineering) able to process 
6 channels. Finally, the number of individuals was 80 female 
individuals, with ages from 19 to 32 years, and an average of 
21.8 years and a deviation of 2.15 years. 


A. Experimental Setup 


The experimental setup consisted of a set of task (stressing 
and non-stressing) in order to collect the data from HR and 
GSR signals in each situation. The procedure is described as 
follows in four steps: 


e First, a relaxing step was carried out at the beginning 
asking kindly the participant to relax some minutes seated 
in a comfortable chair. After some minutes, HR and GSR 
signals were recorded for 120 seconds. This step is called 
Base Line 1, BL1, and corresponds to a non-stressing 
task. 
Afterwards, the participant is required to deeply breath in 
short periods of time, indicated by the experimenter. This 
procedure was carried out till the participant clearly felt 
changes in his or her corporal sensation. At this moment, 
HR and GSR are collected again for a period of time of 
90 seconds. This step is called Hyperventilation, HV, and 
corresponds to a stressing task. 
Third task consisted of asking the participant to prepare 
a short speech on a certain topic during a short period 
of time, being recorded afterwards. Before recording, HR 
and GSR were collected during 90 seconds. Finally, the 
participant was said not to be recorded. This step also 
corresponds to a stressing task, and is called TP. 
Finally, the participant is said to relax, since the experl- 
ment have come to an end, recording in this period the 
physiological signals during 120 seconds. This step is 
defined as Base Line 2, BL2, and there is no certainty 
on the extend of stress of this task (stressing or non- 
stressing), but it can be considered as a post-stress task 
[23], [24]. 

For the sake of task order independence, HV and TP tasks 
were swapped for half of the database population. 

Besides, several psychological tests were carried out to- 
gether with the signal collection. The explanation of this test is 
beyond the scope of this paper, but represents a proper manner 


for detecting a subjective degree of stress provided by the 
individual [26], [27]. 


B. Database discussion 


This data acquisition collects one unique sample of an 
individual of both physiological signals HR and GSR. Notice 
that this psychological experiment is far from being repeatable, 
due to the fact that the specific tasks previously described 
(BL1, HV, TP and BL2) require a component of surprise and 
unexpectedness. In other words, if an individual carries out 
again the same tasks, then the participant could be prepared 
to come through the task, and what is more, the response of 
her or his physiological signals will not be certainly the same. 
This fact justifies that only one sample is considered for each 
individual. 

Furthermore, the stress response of an individual is slightly 
different depending on the stressing task, but similar enough 
to assume that a system trained with this database could 
detect stress on a real-time application [23], [24]. On the other 
hand, despite of having different responses among males and 
females, the behavior of the human stress response is similar 
in both genus, and therefore, the implemented system might 
be able to detect stress also in male individuals [28], [29], 
[30]. 

However, the algorithm responsible for detecting stress has 
been implemented independently of these likely drawbacks, 
since it considers how an individual behaves under both stress 
and relax situation, providing in theory more independence 
from database population. 


TII. STRESS DETECTION 


Human stress response attends the physiological demands 
under abnormal situations. This response is different for 
each individual, and therefore defining a unique criteria for 
stress detection lacks of interest. This scheme proposes a 
stress template for each individual, gathering the behavior of 
physiological signals (GSR and HR) under both stressing and 
non-stressing situations. This template is created based on 
data acquired from an individual, extracted by a mixture of 
Gaussian functions (GMM) [22]. 

Subsequent sections will provide an overview on Gaussian 
Mixture Model (Section IM-A), how the template is extracted 
and which schemes (Section III-B) are proposed to be assessed 
under the Results section (Section IV). 


A. Gaussian Mixture Model 


Four different acquisitions from an individual were collected 
during the experiments. 

Let x be a two-dimensional observation describing a sample 
of both GSR and HR. The probability density function of x 
in the finite mixture form is expressed in Eq. 1 and Eq. 2, 


K 
p(x; 6.) = Y mig(x; pi, Es) (1) 
i=1 
Ñ Ty-—1 
Xx; id = e73(x=H:) Y»; (x—p4) (2) 
9(X; fui, 24) E 
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where K is the number of mixtures, the parameter f. = 
[m;, 14, Es HE, consists of the mixture weight 7, (YX, = 1), 
the mean vector pu, and the covariance matrix *=; of the ¿th 
Gaussian component Vi = 1,2,..., XK, in the c class. In fact, 
Eg. 2 is a specific case with d = 2 [22], [31], since there are 
only two physiological signals, HR and GSR. 

The parameters represented by f/. are estimated by apply- 
ing the Expectation Maximization (EM) algorithm [31]. Let 
(x"41_, be the training samples, then EM algorithm finds 


Q. = argmax UN ,P(x* 0.) (3) 


Section IM-B will define which values of XK (number of 
mixture per class) and c (number of classes) are more suitable 
aiming maximum success in stress detection. 


B. Template extraction 


Considering previous mathematical model, there exist sev- 
eral possibilities for a template extraction. There exist four 
possible classes BL1, HV, TP and BL2, however, BL2 is 
difficult to define as a stressing/non-stressing state, since it 
corresponds to a post-stress state, and therefore, there is no 
possible certainty in which degree of stress involves such 
a state [23], [24]. Thereby, BL2 will not be considered in 
this experiments, and its analysis remain as future work. 
This approach will consider three possible templates, whose 
performance will be compared under the Results Section IV. 


e. Three possible classes, BL1, HV and TP. Data from 
stages BL1, HV and TP is gathered and divided into 
three classes. Each class will be modeled with a unique 
Gaussian, 1.e. HK'=1 and c=3. Figure 1 represents the 
output of the GMM model. Notice how three groups are 
distinguished, namely BL1, HV and TP. 

. Two possible classes, Stress (HV and TP) and non 
Stress (BL1). Stages HV and TP are gathered, since they 
correspond to the same state-of-mind [23], i.e. K'=1 and 
c=2. Figure 2 represents the fact of requiring only two 
possibilities: stress and non-stress. 

+. Modeling each state as one class. This approach differs 
from first approach (three possible classes) in the fact 
that each acquisition from each stage is modeled inde- 
pendently, 1.e. K =1,andc= 1. 


TV. RESULTS 


Since there is only one sample for each user, the data ac- 
quired must be split into several parts in order to obtain enough 
samples for training and testing the proposed approaches. 
However, is it possible to divide the signal into different parts 
and consider those parts as independent samples? The question 
is difficult to be answered, but there exists previous work on 
this topic [12], concluding that it is possible and reasonable 
to state such an assumption. 

Thereby, part of the data acquired of a participant is divided 
into two slots: First part is used to create the template, and the 
other part is used to test the proposed approaches. Considering 
that the device used in this paper (1-330-C2 PHYSIOLAB) 
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Fig. 1. GMM with c= 3. Notice how the algorithm is able to detect properly 
three different regions (BL1, HR, TP). 
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Fig. 2. GMM with c= 2. Notice how the algorithm is able to detect properly 
two different regions (Stress and relax). 


provides an output each second of both HR and GSR, then 
each point of the data represent one second, and therefore, a 
whole data acquisition consists of 420 points. 

The fact of dividing the whole signal into two parts yields 
to the inclusion of two more parameters, namely «a, (time to 
create the template) and 0... (time to acquired data and decide 
to what extend an individual is under stress). For the sake of 
simplicity, av, and Qacy values are stated to 3,5,7,10 and 15 
seconds only. 

Finally, the performance of the stress detection system will 
be evaluated by two parameters: True Stress Detection (TSD) 
which will provide a degree in detecting stress, and True 
Non-Stress Detection (INSD), similar to TSD, but focused 
on detecting relax states. Notice that a stress detection system 
must reach a compromise between these two values, achieving 
the highest values for both parameters. In other words, a rate 
of 100% in detecting correctly TSD could be reached but at 
the expense of TNSD which could be extensively decreased. 
Therefore, a compromise between TSD and TNSD must be 
achieved. 
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e=3 e=%2 e=1 
95.1+ 02%  934>3+0.2% 96.2 +0.2% 
TSD Qacq = 98 Oacq = 18 Qacq = 98 
as = 10s 04 = Ts o4 = 158 
86.3+ 0.4%  82.3+0.7% 86.5 +0.5% 
TNSD Qacq = 98 Aacq = 98 %acq = 38 
os = Ts 04 =Ts o4 = 10s 
TABLE I 


STRESS DETECTION ACCURACY (TSD AND TNSD) OBTAINED IN 
RELATION TO TEMPORAL PARAMETERS Q%acq AND Qt. 


A. Temporal parameters 


The temporal parameters measure the time required to detect 
stress. In fact, a high value in Q.g. might indicate that this 
system is not suitable for real-time applications. Therefore, 
the relation between Qqcy, 4 and the performance rates (TSD 
and TNSD) of each approach must be studied, in order to 
obtain the combination of previous temporal parameters which 
minimize the stress detection rates. Obviously, there is also a 
compromise in here: the more time the system takes to detect 
stress, the higher the performance, but to what extend is the 
system able to detect stress by minimizing Waeg and a? 


B. Stress Detection accuracy 


Finally, the overall performance for each approach with 
optimal values of 0,. and o is provided in Table 1. 

The system is able to detect stress with 96.2 +0.2% of 
accuracy, and relax state with 86.5 +0.5% both for the third 
approach based on one class for each stage. This results 
are promising if compared to other results available in the 
literature considering physiological signals, which obtained 
rates of 97.4% using an acquisition time of 5 minutes [32], 
79.5-96.6% [33], 85-96% [25], 75-85% [7], 76% [17] and 60- 
78% [34]. 


V. CONCLUSIONS 


A stress detection system based on GMM has been presented 
with promising results. Rates of True Stress Detection of 
96.2 + 0.2% yields to the conclusion of a precise stress 
detection. Furthermore, the required time to elicit this results 
are suitable for real-time applications: a time of 5 seconds to 
extract the information on the state-of-mind of the user. 

These results yield the conclusion that this system is suitable 
for scenarios of intrusion detection. Moreover, this stress 
detection system can present an improvement in terms of 
security for current biometric applications, since the system 
1s very easy to be embedded on biometric systems. 

Finally, an improvement of this technique and research 
with different methods remain as future work, together with 
an embedded implementation of this system, integrating both 
software and required hardware. 
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Abstract—JXME is the JXTA specification for mobile devices 
using J2ME. Two different flavors of JXME implementation 
are available, each one specific for a particular set of devices, 
according to their capabilities. The main value of JXME is its 
simplicity to create peer-to-peer (P2P) applications in limited 
devices. In addition to assessing JXME functionalities, it is also 
important to realize the default security level provided. This 
paper presents a brief analysis of the current state of security 
in JXME, focusing on the JXME-Proxyless version, identifies 
existing vulnerabilities and proposes further improvements in 
this field. 


I. INTRODUCTION 


Peer-to-peer (P2P) networks allow peers to provide and 
consume services in a collaborative way. Examples of these 
services are content sharing, processing and messaging. In this 
kind of network, it is assumed that all peers have equivalent 
capabilities, as well as a high degree of decentralization and 
autonomy. 

P2P technology, that has been widely used in traditional 
wired network environments, is now moving to the mobile 
paradigm [1] since new wireless technologies are becoming 
more available (WLAN, 3G, 3.5G,...) and more powerful hand- 
held devices (like smart phones or mobile Internet devices, 
MID) have been developed. However, the massive deployment 
of P2P mobile applications may depend on the tools available 
for developing such applications in a transparent way. 

There are different platforms that allow programmers to 
develop mobile P2P applications ([2], [3], [4]). One of these 
platforms is JXME [4], a set of open protocols specifications 
that enables the creation and deployment of P2P networks 
over mobile devices. The advantage of JXME, in front of 
other proposals, is that it is the mobile version of the well 
known JXTA platform [5]. JXTA is a set of protocols which 
allow peers to communicate, publish and find resources, and 
consume remote resources, independently of the actual trans- 
port layer and the implementation language. JXME allows 
mobile devices to create a mobile JXTA network and also 
to participate in a “wired” standard JXTA network. JXME 
heavily takes into account the idiosyncrasies of mobile devices 
such as power and storage limitations, and for that reason 
research has focused on these features [6]. However, security 
1s a very important issue that has been often forgotten in JXME 
research. 

The main goal of this paper is to analyze the security 
mechanisms that JXME provides. Such analysis should allow 
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to determine which will be the minimum security features 
included in P2P mobile applications developed on top of 
JXME. We based our study in JXME-Proxyless, one of the two 
available JXME versions, since it is the most complex one and 
the one where peers are actually self-organized. The security 
analysis performed in this paper follows the idea of [7] where 
a generic JXTA security survey has been presented. Applying 
the same methodology, security is not analyzed by reviewing 
basic peer operations in an isolated manner, but taking into 
account the whole peer life cycle. With this approach, it is 
possible to identify the available security mechanisms and how 
they operate. 

The paper is organized as follows. Section II provides 
an overview of the JXME project. Section III presents the 
security analysis of JXME-Proxyless. Section IV provides a 
brief comparison between both versions of JXME. Finally, 
Section V outlines the conclusions and further work. 


TI. OVERVIEW OF JXME 


Currently, only Java implementations of JXME exist. They 
are direct offshoots of the generic JXTA specification, thus 
sharing many characteristics with the desktop version. A 
detailed explanation of JXTA's generic protocols and services 
can be found in [8], however, we will briefly outline the most 
important concepts. 

In both cases, JXTA and JXME, the architecture is com- 
pletely based on the concept of Peer Groups, sets of peers 
with common interests which agree on shared services. Peer 
Groups are managed by the Membership Service, one of 
JXTA's core services. Once a peer has joined a Peer Group, 
any resource may be shared with other group members by 
distributing its associated Advertisement, an XML metadata 
document describing the resource properties and how it may 
be accessed. Advertisements are located and distributed using 
the Discovery Service. A network resource cannot be accessed 
without previously recovering its associated Advertisement. 
Every time an Advertisement is retrieved by a peer, it is stored 
in the local cache and assigned an expiration date. At that 
date, the Advertisement will be automatically flushed. Once a 
resource has been located, messaging may begin using JXTA 
pipes, abstract endpoints which provide an asynchronous uni- 
directional communication channel. 

Therefore, the Java implementation of JXME can be viewed 
as a JXTA compatible platform for resource constrained de- 
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vices, based on the framework specifications for Java ME: 
Comnected Device Configuration (CDC) and Connected Lim- 
ited Device Configuration (CLDC). The CDC specification 
uses the C-Virtual Machine (CVM), an optimized version of 
the Java Virtual Machine (JVM) [9], it contains some of the 
standard Java packages, and it is addressed towards high end 
mobile devices, such as powerful PDA's and smart phones. 
In contrast, the CLDC specification uses the Kilobyte Virtual 
Machine (KVM) [10], which has few of the standard Java 
packages, thus being suitable for lower end devices with very 
slow processors and very reduced memory. CLDC is further 
divided into two profiles which define its operation mode: 
Mobile Information Device Profile (MIDP) and DOcomo JAva 
(DOJA). The former is a specification for the usage of Java 
on embedded devices and the latter is a Java environment 
specification for DoCoMo's i-mode mobile phone. 

Using JXME, any CDC/CLDC device can participate in 
the JXTA network and exchange messages with any other 
peer. Unfortunately, because of the limited capabilities of 
mobile devices, they cannot fulfill some of the JXTA peer 
basic functions such as encoding JXTA messages in XML, 
maintaining a local copy of the network state and listening to 
incoming network information at socket or datagram level. 
Two distinct versions of JXME currently exist, each one 
suitable for a different set of mobile devices. On one hand, 
the JXME-Proxied version is a very simple implementation 
for limited devices, which delegates all the heavy work to 
an external super-peer, the Relay Peer. On the other hand, the 
JXME-Proxyless version is a more complex one, where mobile 
peers may directly interact with the JXTA network. 

In this paper we focus in the JXME-Proxyless version. We 
consider it is the most interesting one, since it is the most 
complex and the one where peers are actually self-organized. 
However, we will provide insights on JXME-Proxied in Sec- 
tion IV. 


A. JXME-Proxyless version 


The JXME-Proxyless version currently holds the newest 
and most complete implementation of JXME, having been 
expected by the community for years. This version is the 
nearest one to the JXTA specification, allowing mobile devices 
to directly participate into the JXTA network by themselves, 
without the need of an external super-peer. Figure 1 shows 
the JXME network architecture and how it interoperates with 
a desktop JXTA network. However, the most advanced func- 
tionalities of desktop JXTA, such as the Shared Resource 
Distributed Index (SRDD [11], have been implemented as 
lighter versions, taking into account the limited capabilities 
of mobile devices. 

Any peer using JXME-Proxyless is named a Proxyless Peer 
and is able to perform the following actions by itself: 


+. Discover other devices and services. 

+. Publish Advertisements about it's own resources. 
+ Establish direct connections to any other peer. 

. Create/join private virtual domains (Peer Groups). 


Proxied 


Proxyless 


Fig. 1. JXTA and JXME network architecture 


. Directly exchange/access content with other Peer Group 
members. 


Proxyless Peers may use JXTA's most important compo- 
nents: Peer Groups, Advertisements and Pipes. Since Proxy- 
less Peers may directly interact with other peer group members 
under a secure context, Peer Groups are necessary to maintain 
JXTA's architecture. Advertisements are encoded using XML, 
just like in the desktop version, in order to maintain language 
independence. Finally, in spite of its complexity, Pipes are 
available since direct TCP communications are supported. 

However, Proxyless Peers have some limitations on regards 
to the JXTA base architecture. First of all, even though most 
JXTA services are implemented, some of they are not, and 
even when a particular service exists, it must be taken into 
account that it may not have full capabilities. An obvious 
example is the Membership Service, which does not support 
all implementations available in desktop JXTA. Furthermore, 
another constraint is that a Proxyless Peer cannot act as a 
super-peer in a JXTA network. As a result, since super-peers 
help network management, such as caching Advertisements 
to accelerate search queries, a JXTA network formed only by 
Proxyless Peers may have scalability issues. 

Finally, 1t is also important to point out that, since Proxyless 
Peers directly participate in the JXTA network (forwarding 
messages, finding routes, saving Advertisements, etc.), they 
have to pay a cost in resource consumption, such as battery 
power, even when the mobile device is in standby mode. 


B. Related work 


Some research exists on JXTA, enhancing its basic features 
[11] and security [7], but not many efforts have been made 
for JXME specifically. 

In [12] an analysis about JXME functionality is found, 
concluding that JXME-Proxied is not suitable for MANET en- 
vironments because of its centralized architecture but JXME- 
Proxyless can fit well in this type of environments. A frame- 
work for mobile devices optimized to MANET networks 
which is compatible with JXTA protocols is developed in 
[13]. In [14] a framework to allow JXME devices to use 
bluetooth is presented. This framework permit devices to 
overcome Bluetooth limitations, such as the maximum number 
of interconnectable devices and the maximum transmission 
range. 
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JXME has also been analyzed and used to build a set of 
applications. For instance, in [15] JXME-Proxyless is used to 
implement a distributed collaborative platform which makes 
people in distributed spaces ubiquitous collaborate with friends 
and colleagues. 

However, regarding security, to our best knowledge, there 
is no attempts to identify nor improve the JXME-Proxyless 
security properties. 


TIT. JIXME-PROXYLESS SECURITY ASSESSMENT 


Guaranteeing a minimum security level should be one of 
the main goals in most of the current P2P applications, even 
though this level may differ depending on the particular needs 
of each application. In this section, a security analysis of 
JXME-Proxyless is made in order to evaluate the security level 
currently provided by the platform. This analysis follows the 
methodology used in [7], where the general peer life cycle is 
examined rather than isolated peer actions. 

The standard JXME-Proxyless general operation cycle can 
be summarized in the following steps [7]: Platform startup, 
Peer Group joining, Resource discovery and publication, Mes- 
sage exchange and Disconnection. A brief description of each 
step follows: 


1) Platform startup: This is the first action performed by a 
JXTA Peer and consists in loading the required libraries 
and initializing the system prior to going online. 

2) Peer Group joining: At this step, the peer joins a Peer 
Group, so interaction with other Peer Group members 
1s possible. Peer Group joining is managed by the 
Membership Service, one of JXTA's core services, which 
allows peers to claim unique identities within a Peer 
Group. 

3) Resource discovery and publication: Encompasses the 
distribution and location of Advertisements and how to 
access it. This action is performed via JXTA's Discovery 
Service. 

4) Message exchange: This is the most frequent action 
in Proxyless Peers, consisting of data exchange, usually 
in order to access resources, such as available services. 
This exchange can only exist between same group 
members and is accomplished using JXTA pipes. 

5) Disconnection: Peer cleanup before exiting the JXTA 
network. This is the last action a peer performs before 
going offline. 


A. Attacks in P2P networks 


In order to perform a security assessment, it is useful to 
identify and categorize the most common attack types in P2P 
networks. All attacks can be divided into two distinct groups, 
according to the degree of involvement of the attacker [16]: 
passive attacks, where the attacker just monitors peer activity 
and network traffic, and active attacks, where the attacker 
purposely interferes with network activity. Each group can be 
further classified according to the particular action performed 
by the attacker. 

We are interested in the following attacks: 


Passive attacks: 

. Eavesdropping (Evs): Searching, in message exchanges, 
for sensitive information such as passwords. 

e Traffic analysis (TAn): Analyze traffic data, looking for 
patterns and relevant peers. 


Active attacks: 

. Spoofing (Spf): Impersonating another peer. 

+. Man-in-the-middle (MitM): Intercepting the communica- 
tions between two parties, transparently relaying forged 
messages to each one. 

. Playback (Pb) or Replay (Rp): Capturing messages so 
they can be reused at a later time, simulating a real 
message exchange initialization. 

e Local data alteration (LDA): Modifying local data to 
corrupt the system behavior. 

. Software Security Flaws (SSF): Exploiting vulnerabilities 
due to bugs in the source code trying unexpected actions 
on the software. 


B. JXME-Proxyless Security evaluation 


From the peer operation cycle and the identification of 
possible attacks, it is possible to provide a structured security 
assessment. To identify which vulnerabilities exist, we have 
designed and performed some attacks which try to subvert 
JXME operations. Our analysis is focused in active attacks, 
since they need technical knowledge about the JXME archi- 
tecture, and rely on active operations to exploit vulnerabilities. 
Passive attacks are more generic and can be performed using 
common tools, such as sniffers [17]. 

1) Platform startup: The first action a Proxyless Peer 
performs consists in loading the JXTA libraries and creating 
the default network manager. This operation does not perform 
any network activity, and thus is protected from external 
interference at this level. The only vulnerabilities that exist are 
those related to library authenticity. Since no mechanisms are 
provided to differentiate a good JXME-Proxyless distribution 
from a malicious one, it is possible to subvert the system via 
local data alteration attacks. 

To prove this flaw, we have designed an attack where 
an original Proxyless Peer (P¡) tries to send messages 
to a hacked Proxyless Peer (P3), who uses a modified 
JXME-Proxyless library. The attack consists on removing 
the content of the publish and remotePublish methods inside 
the net.jxta.impl.discovery.DiscoveryServicelmpl class. Both 
methods are used to publish and propagate Advertisements 
to other peers. Therefore P3 is not able to distribute his 
Advertisements over the JXTA network. These changes make 
P. unreachable from P, and from the JXTA network, since its 
Peer Advertisement, needed by P, or any other peer to route 
messages to him, is never published. 

2) Peer Group joining: The step of joining a Peer Group 
is handled via the JXTA Membership Service. This is one 
of JXTA's core services, which manages the group members” 
identities within the group context. Identities are assigned 
by successfully completing an authentication process prior 
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to actually joining the group. The Membership Service is 
defined as generic in the JXTA specification, leaving up to 
developers to implement their own version, with the security 
level required by their applications. 

Even though JXTA provides some reference implementa- 
tions for the Membership Service, JXME-Proxyless provides 
none at all, allowing any Proxyless Peer to create and join any 
Peer Groups. Since no Membership Service is implemented, 
no security really exists for the join operation, and no au- 
thentication process is enforced, allowing any peer to claim 
any identity within the system. We tested this security flaw 
by running two Proxyless Peers that execute a demo chat 
application provided with the JXME-Proxyless library. Both 
peers exchange messages inside a newly created Peer Group. 
Additionally, we have also created an additional peer who can 
join this new group, but claiming any identity. This peer is 
able to send messages to other group members. 

3) Resource discovery and publication: In JXTA and 
JXME-Proxyless, resources are published across the JXTA 
network by distributing an Advertisement. The JXTA speci- 
fication defines Advertisement security at two distinct levels: 
at Advertisement level and during its transport. In the former, 
the secure layer data is directly included in the Advertisement 
as additional content, whereas in the latter, the Advertisement 
is processed as a simple message. Security at message layer 
will be discussed in Section III-B4. 

As far as Advertisement level security is concerned, JXME 
does not provide any security mechanism. Advertisements are 
transmitted without any kind of privacy over the network, 
thus becoming vulnerable to eavesdropping attacks, as well 
as traffic analysis, since an attacker can identify important 
Proxyless Peers (those with many resources) by the amount 
of published Advertisements. 

Furthermore, we have designed and performed a Spoofing 
attack on Advertisement exchanges, where there are two 
Proxyless Peers (P, and Po) exchanging messages, and a 
malicious Proxyless Peer (P3) trying to impersonate Pz. The 
structure of this attack is shown in Figure 2 and follows the 
steps: 

1) P, publishes his Peer Advertisement, containing his 

route address. 

2) Since no mechanism is provided to authenticate peers, 
P3 can publish a Peer Advertisement using Po*s identi- 
fier but including P3?s address. Once this Peer Adver- 
tisement is propagated across the network, 1t will replace 
the original P, Peer Advertisement. 

3) Before P, can send a message to P», it has to ask for 
Po's Peer Advertisement to the super-peer. 

4) A super-peer sends Po,'s Peer Advertisement to P;. 

5) P, tries to send a message to Pa, but he will actually 
send it to P3 instead. This attack will be reverted when 
Po, republishes his Peer Advertisement. 

Moreover, a vulnerability inherited from JXTA still exists. 
In JXTA, super-peers are responsible for the propagation of 
Advertisements over the JXTA network. However no mech- 
anisms to identify false ones exist. Therefore, a malicious 


Super-peer 


5. Send 
Message to P2 


Fig. 2. Spoofing attack 


super-peer can perform a Man-in-the-middle attack between 
Proxyless Peers inside different networks, and modify any 
information in the Advertisements prior to propagating them 
over the network. 

As far as local data alteration is concerned, since Proxyless 
Peers” local cache is stored in RAM, and no persistent copy 
ever exists, they are protected on the long term. 

4) Message exchange: This 1s the most common operation 
in Proxyless Peers, and therefore, where more efforts have 
been made by developers to implement security mechanisms. 
Proxyless Peers exchange messages using pipes, unidirectional 
and virtual connections between abstract endpoints. JXME- 
Proxyless supports two different pipe types: Unicast and 
Propagate. Both are considered unreliable, the former being 
used for point-to-point communication whereas the latter for 
one-to-many message broadcast. 

Unfortunately, both pipe types have some security issues: 

e All data is sent in clear, and thus vulnerable to eaves- 
dropping. 

+ Any data sent through a pipe may actually hop across 
other peers before reaching the intended destination, 
which makes the transmission prone to man-in-the-middle 
attacks. 

e. There is no assurance that a pipe is connected to the 
specified peer (Spoofing). 

Fortunately, developers are currently working in the imple- 
mentation of a wire transport level security layer that may 
be applied to pipes. This security layer is based in JXTA's 
own definition of Transport Layer Security (TLS) [18]. This 
definition is based on two distinct protocols: 

+ Handshake Protocol: Initial TLS negotiation protocol, 

responsible of the authentication between both peers. 

. Record Protocol: Provides a private and reliable com- 
munication channel by encrypting data using symmetric 
cryptography and using integrity check. 

This implementation basically allows private, mutually au- 
thenticated and reliable communication, protected against both 
passive and active attacks. Pipes based on TLS are named 
UnicastSecure, greatly improving JXME-Proxyless security. 
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However, after performing several tests, we have realized 
that UnicastSecure pipes provide a secure communication 
channel but remain unreliable. It is possible to receive an 
acknowledgement from your messenger without the message 
actually having been sent. This is because they have been 
built using the NonBlockingOutputPipe java class. Moreover, 
to perform secure communications using UnicastSecure pipes, 
an external certificate authority (CA) responsible to manage 
certificates is required. 

Furthermore, unfortunately, UnicastSecure pipes are re- 
stricted to point-to-point communications, and therefore can- 
not be used for message broadcast, which is quite common 
in a Peer Group context. In addition, no traffic masquerad- 
ing mechanism is implemented, so it is still open to traffic 
analysis. Finally, the classes needed to implement TLS are 
not included in the common libraries provided by Java ME. 
The Foundation Profile is required, an optional package which 
is a standard Java specification and is defined by the Java 
Community Process (JCP) in JSR 219 [19]. 

3) Disconnection: Since this operation does not require any 
communication using the network, no security vulnerabilities 
exist. This step in JXME-Proxyless is included just for the 
sake of completeness. 


C. Evaluation summary 


Even though no software is fully free from bugs, it can 
be considered that JXME-Proxyless has a big advantage be- 
cause of its Open Source Software (OSS) nature [20]. Being 
supported by a community of enthusiastic developers, it can 
be considered relatively safe from Software security flaws on 
regards to security. 

The analysis of possible attacks and the existing security 
mechanisms of JXME-Proxyless, classified by peer operations, 
provides a vulnerability map summarized in Table IL. Attacks 
are those described in Section HI-A, indexed by abbreviation. 

From our experiments, it can be concluded that JXME- 
Proxyless is vulnerable to the following kinds of attacks: 

. V(1): Malicious executable code can easily be built and 

cannot be automatically discovered when installed. 

+. V(2): No encryption mechanism exists. Advertisements 

are transmitted in plain text. 

+. V(3): No data flow masquerading mechanism exits. It is 

easy to identify important peers by its traffic. 

+. V(4): No repudiation method exists. Any peer can publish 

Advertisements in name of any peer. 

+. V(5): No repudiation or encryption method exists. Any 

peer can modify Advertisements. 


The available security mechanisms are: 
. P(TLS): Transport Layer Security 


TV. BRIEF COMPARISON BETWEEN JXME-PROXYLESS 
AND JXME-PROXIED 


Even though we have focused on the JXME-Proxyless 
version, in this section we highlight the main differences 
with the JXME-Proxied security model. Such differences are 


mainly due to JXTA Proxied's much more minimalist design, 
which relies on a centralized approach. Any peer using JXME- 
Proxied is named a Proxied Peer and since they are assumed 
to have very limited resources, cannot directly communicate 
with other peers within the JXTA network. All messages are 
exchanged through a Relay Peer, a special kind of super-peer 
which implements the Relay and Proxy JXTA services. 

The communication between Proxied and Relay Peers is 
performed with a simplified protocol based on HTTP. This 
protocol is performed exchanging text plain messages which 
contain the operation to execute. The available operations are 
predefined: Join a group, Search or Create resources (such as 
Peer Groups or pipes), Listen to a pipe to receive data, Send 
data to a specific pipe, Close a pipe and Poll the Relay Peer 
for incoming messages from the JXTA network. Basically, 
1t means that Proxied Peers delegate JXTA communications 
to the Relay Peer and only execute the previous mentioned 
Operations. 

The most important difference between both JXME versions 
is that a Proxied Peer needs a Relay Peer to participate in 
the JXTA network. Therefore, during the platform startup 
operation, a Proxied Peer, in addition to loading the required 
libraries, needs to connect to any available Relay Peer. In 
this initial communication, the Relay Peer creates the Peerld 
for the Proxied Peer and sends it in plan text. Since Relays 
Peers are only able to identify Proxied Peers by their Peerlds, 
interception becomes a security vulnerability. 

In JXME-Proxied, unlike Proxyless, Proxied Peers can only 
join to Peer Groups which implement the None Membership 
Service, the default Membership Service in JXTA. It is de- 
signed for applications with no security concerns, being used 
in groups without authentication, where any peer can claim any 
identity. There is an initial implementation of a Membership 
Service based on passwords, the Passwd Membership Service. 
However, as mentioned in the JXTA documentation, it was 
designed only for testing, since passwords are still transmitted 
in clear text across the network. Therefore, we can consider 
that no effective security is implemented in JXME-Proxied at 
the join operation. 

As far as Advertisement publication is concerned, in con- 
trast to JXME-Proxyless, where they are encoded in XML, 
JXME-Proxied exchange plain text messages, because in lim- 
ited devices a XML parser is not feasible. But in terms of 
security, no security layer over Advertisements is provided 
either. Therefore, both versions share the same vulnerabilities. 

Another important difference in JXME-Proxied exists in the 
message exchange step. In JXME-Proxied it is only possible to 
perform outbound HTTP connections, in contrast with JXME- 
Proxyless where direct input and output TCP connections 
are allowed. That's one of main the reasons why Relay 
Peers are required. This approach tries to mitigate resource 
consumption, since Proxied Peers not being directly connected 
to the JXTA network, they do not have to forward messages, 
find routes or save Advertisements. However, in terms of 
security, while Proxyless Peers can directly send the data in 
a secure way, Proxied Peers send it in simple text, becoming 
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Operation/Threat Evs TAn Spf MitM Rp LDA SFF 

Startup N/A N/A N/A N/A N/A vV() || P(OSS) 

Join* N/A N/A N/A N/A N/A N/A || P(OSS) 

Publish/Discover v(2) V(3) v(4) V(5) N/A N/A [| P(OSS) 

Messaging P(TES**) | V(B) | POTLS**)  P(TLS**) | PCTLS**) | N/A [| P(OSS) 

Disconnect N/A N/A N/A N/A N/A N/A [| P(OSS) 
TABLE I 


JXME-PROXYLESS PEER OPERATION CYCLE SECURITY SUMMARY 
(N/A: NON-APPLICABLE. V(TYPE): VULNERABILITY EXISTS. P(MECHANISM): SECURITY MECHANISM USED) 
(F*STEP NOT ACTUALLY IMPLEMENTED IN JXME-PROXYLESS) 
(**NOT USABLE FOR MESSAGE PROPAGATION) 


totally vulnerable to passive and active attacks. 

Finally, the Disconnection operation is different in JXME- 
Proxied, since it is not explicit. A Relay Peer decides when 
to unsubscribe any Peer or a Peer Group. Proxied Peers can 
only perform an operation to close a pipe by knowing its 
id. However, it means that a Proxied Peer is vulnerable to 
spoofing, even when it is disconnected, until the Relay Peer 
decides to actually unsubscribe it. 


V. CONCLUSIONS AND FURTHER WORK 


Even though JXME-Proxyless is supposed to be a version 
conceptually very similar to desktop JXTA, with lightweight 
versions of the original core services, its security capabilities 
are still at its infancy. Only secure pipes have actually been 
paid attention by the developers. This is one of the evidences 
that being an OSS project is both boon and bane. On one 
hand, anyone may audit the code, looking for flaws, and 
contribute to the project. But on the other hand, implementing 
actual improvements whole depend on contributors” goodwill 
or interest. 

From the security analysis of the JXME-Proxyless, it can 
be concluded that, in the current version, developers have 
started to take into account security, with the inclusion of TES. 
Unfortunately, 1t is important to highlight that only using TLS 
is not enough to protect the system, since an attacker can 
easily claim any identity and impersonate any Proxyless Peer 
during Advertisements publication. Therefore, there's still a 
lot of work pending. Finally, we can also conclude that the 
JXME-Proxied version, were priority is in performance and 
not security, does not have an appropriate security baseline, 
because messages are exchanged with the Relay Peer in clear 
text, and no powerful authentication method is provided. 

Further research includes providing JXME-Proxyless with 
an actual Membership Service, to provide authentic peer iden- 
tities within a Peer Group. Once this service is established, it 
1s possible to protect Advertisements. All these improvements 
should heavily take into account the idiosyncrasies of mobile 
devices, in contrast to a desktop environment. 
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Resumen—El incumplimiento de las leyes origina la imposición 
de sanciones. Una buena gestión de las sanciones se convierte 
en un factor clave para que éstas sean eficaces. Por este 
motivo, se han producido impulsos legislativos que persiguen el 
desarrollo electrónico de los procedimientos. No obstante, hasta 
el momento no se ha propuesto la realización electrónica del 
procedimiento sancionador completo en el ámbito del control del 
tráfico vehicular. En este trabajo se propone un modelo para 
la implantación del procedimiento sancionador electrónico en 
dicho contexto, mejorando la capacidad de participación de los 
ciudadanos interesados en el mismo. Particularmente y por las 
implicaciones legales del procedimiento, se abordan en detalle los 
aspectos de seguridad necesarios. 

Palabras clave: Procedimiento sancionador electrónico, tráfico, 
sanción, seguridad. 


I.. INTRODUCCIÓN 


A través de la legislación, los estados determinan qué ac- 
tuaciones están permitidas dentro de su territorio. El incumpli- 
miento de las leyes lleva consigo la imposición de una sanción, 
que debe ser proporcionada y justa. Para garantizar la obser- 
vancia de estos principios, se ha definido un procedimiento 
específico para el establecimiento de las sanciones. 

El procedimiento sancionador abarca todo el ciclo de ges- 
tión de la sanción, desde la observación del mal cometido hasta 
que se establece definitivamente la sanción correspondiente. 
Actualmente, dicho ciclo lleva asociada una notable carga 
burocrática. Esto origina una gran cantidad de documenta- 
ción y, al mismo tiempo, la dilatación en el tiempo de los 
procedimientos. Ambas cuestiones han desembocado en una 
gestión ineficiente de las sanciones, provocando incluso que 
haya procedimientos que caduquen sin haberse establecido una 
sanción. 

Los impulsos recientes para la agilización de la Adminis- 
tración Pública tienen por objetivo paliar estos defectos en la 
ejecución de los procedimientos. En España, esta voluntad se 
materializó en la Ley 11/2007, de acceso electrónico de los 
ciudadanos a las Administraciones Públicas [1]. Dicha Ley 
especifica, entre otras cuestiones, las directrices para la gestión 
electrónica de procedimientos administrativos. 

Uno de los ámbitos donde se gestionan un mayor número 
de procedimientos administrativos es el control del tráfico 
vehicular (4,7 millones de procedimientos en 2008). A la vista 
del elevado volumen de tramitación, la adopción de medios 
electrónicos (con sus beneficios previstos de transparencia, 
eficacia y eficiencia) se hace especialmente necesaria. Hasta el 


Ihttp://www.dgt.es/portal/es/seguridad_vial/estadistica 


momento, sin embargo, no existen propuestas que aborden de 
manera electrónica todas las fases del procedimiento. Además, 
las contribuciones que abordan parcialmente este proceso no 
explotan las ventajas que brinda el desarrollo actual de las 
tecnologías de la información y que permitiría la interacción 
en tiempo real con el sancionado y los demás interesados en 
el procedimiento. 

El objetivo de este trabajo es proponer un nuevo modelo 
de procedimiento sancionador electrónico aplicado al control 
del tráfico. Dicho modelo abarca todas las fases del proceso, 
promoviendo la participación directa de los interesados en 
ellas. Además, el modelo respeta las directrices establecidas 
por la citada Ley 11/2007, prestando especial atención a los 
aspectos de seguridad. 


FA. Organización del trabajo 


La Sección II describe el proceso sancionador y presenta las 
normas específicas de gestión electrónica de procedimientos 
según la Ley 11/2007, con especial atención a las cuestiones 
de seguridad que ésta plantea. En la Sección III se presentan 
los principales antecedentes para la realización electrónica del 
procedimiento. La Sección IV describe el modelo propuesto, 
analizando sus aspectos de seguridad y presentando un análisis 
preliminar de la viabilidad técnica del mismo. La Sección V 
presenta los trabajos relacionados y, finalmente, la Sección VI 
recoge las principales conclusiones y líneas de trabajo futuro. 


II. EL PROCEDIMIENTO SANCIONADOR EN ESPAÑA. 
REALIZACIÓN ELECTRÓNICA 


El objetivo de este trabajo es mejorar el procedimiento por 
el cual se establecen sanciones administrativas en un ámbito 
concreto (el control del tráfico). En esta Sección se describe 
dicho procedimiento y las consideraciones de seguridad pre- 
vistas en la Ley 11/2007. 


IIT-A. Descripción del procedimiento sancionador 


El procedimiento sancionador queda originalmente definido 
en España en la Ley 30/1992 [2]. Sin embargo, la Ley 
11/2007 supuso una renovación significativa del mismo, al 
proponer su realización electrónica a través de las tecnologías 
de la información. De hecho, dicha Ley reconoce el derecho 
de los ciudadanos a relacionarse con las Administraciones 
Públicas por medios electrónicos [1]. Con ello, se pretende 
mejorar su transparencia, su eficacia y su accesibilidad para 
los ciudadanos. 
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Figura 1. Procedimiento sancionador actual 


La Figura 1 describe los diferentes elementos que intervie- 
nen en el procedimiento sancionador, incluyendo los medios 
electrónicos que la citada Ley 11/2007 contempla para su 
realización. Dicho procedimiento se compone de tres fases 
(Figura l, arriba): iniciación, instrucción y resolución. 

La fase de iniciación puede ser comenzada por cualquier 
testigo del hecho, presentando una solicitud a través de un 
registro. Esta presentación puede realizarse de forma electróni- 
ca a través de un registro (electrónico), aportando la copia 
digitalizada de los documentos que en su caso acompañen a la 
solicitud. Una vez recibida, la solicitud se evalúa, aceptándola 
o rechazándola en función de los hechos descritos. En el 
caso de que se acepte, se obtienen los antecedentes y datos 
personales que serán necesarios para establecer la sanción. Una 
vez se ha establecido la sanción correspondiente (siempre bajo 
el supuesto de que los hechos fueran ciertos), se crea la notifi- 
cación de la iniciación del proceso. Esta notificación se envía 
a la dirección postal del implicado, salvo que el ciudadano 
haya permitido el envío a través de medios electrónicos, en 
cuyo caso así se procede. 


Tras la fase de iniciación comienza la de instrucción. En 
ella los interesados pueden formular alegaciones O proponer 
la práctica de pruebas que permitan adecuar la sanción a 
la gravedad de los hechos. Así, se puede presentar el testi- 
monio de otras personas presentes en el suceso (alegación) 
O proponer una pericia técnica sobre el funcionamiento de 
un dispositivo (prueba). Esta presentación se puede realizar 
a través del registro electrónico. Tras la valoración de los 
resultados arrojados por las alegaciones y las pruebas, el 
organismo instructor efectúa una propuesta de resolución que 
es nuevamente enviada a los interesados. 


Una vez finalizada la instrucción, un organismo distinto del 
instructor se encarga de la resolución, en el que se valora la 


propuesta de resolución y se redacta la resolución definitiva 
que pone fin al proceso sancionador. 

La tramitación electrónica da lugar a dos nuevos servicios 
adicionales para el ciudadano relacionados con el procedi- 
miento (Figura 1, derecha). Por un lado, el ciudadano puede 
consultar electrónicamente los actos de trámite (incluyendo su 
contenido) y la fecha en que se hicieron. Por otro, el ciu- 
dadano puede obtener copias electrónicas de los documentos 
electrónicos que ya formen parte del procedimiento. 


II-B. Necesidades de seguridad para la realización electróni- 
ca del procedimiento sancionador según la Ley 11/2007 


Para la ejecución electrónica del procedimiento, la Ley 
contempla una serie de mecanismos técnicos y, sobre éstos, 
establece ciertas necesidades de seguridad. En este apartado se 
revisan estas cuestiones, que afectan a dos aspectos distintos: 
la información del procedimiento y a las relaciones con el 
ciudadano. 

En cuanto a la información del procedimiento, se recoge 
en el expediente electrónico, que contiene documentos ad- 
ministrativos electrónicos. Ambos elementos están firmados 
electrónicamente, a fin de asegurar su integridad e identificar 
fehacientemente el órgano responsable. Los documentos deben 
contener, además, una referencia temporal que se presume 
confiable. Toda esta información se deben almacenar en un 
archivo electrónico, al cual se le exige que proteja la inte- 
eridad, autenticidad, confidencialidad, calidad, protección y 
conservación de los documentos guardados. Igualmente, se 
impone el uso de mecanismos de control de accesos y, en 
general, que se satisfaga lo dispuesto en la legislación de 
protección de datos personales. 

En cuanto a las relaciones con el ciudadano, se distinguen 
dos elementos: los registros y la comunicación electrónica. Los 
registros electrónicos se encargan de recibir y enviar todos 
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los documentos, escritos y solicitudes que tengan lugar en 
un determinado procedimiento. Dichos registros deben tener 
plena disponibilidad. Además, por cada documento aportado 
por el ciudadano, el registro debe emitir un recibo acreditativo. 
Dicho recibo consiste en una copia autenticada de lo aportado, 
incluyendo la fecha y hora de presentación y el número de 
entrada en el registro. 

Finalmente, en la comunicación electrónica con el ciuda- 
dano debe quedar constancia de la transmisión y recepción, de 
sus fechas y del contenido íntegro comunicado. Así mismo, 
debe identificarse fidedignamente al remitente y al destinatario. 
Si en esa comunicación se envía una notificación electrónica, 
debe reflejarse la fecha y hora de la puesta a disposición 
del interesado de lo notificado, así como la de acceso a 
su contenido. Los medios empleados para este fin deberán 
asegurar su disponibilidad, a fin de garantizar el acceso de los 
ciudadanos a los procedimientos. 


TI. ANTECEDENTES DE TRAMITACIÓN ELECTRÓNICA DE 
SANCIONES DE TRÁFICO CON LA PARTICIPACIÓN DEL 
VEHÍCULO 


Las redes vehiculares, habitualmente referidas como VA- 
NET (del inglés Vehicular Ad-hoc NETwork) son un tipo 
específico de red móvil de comunicación [3]. A través de 
estas redes los vehículos intercambian datos entre sí y con 
sistemas externos. Dichos intercambios de información per- 
miten construir nuevos servicios electrónicos, denominados 
Sistemas Inteligentes de Transporte (SIT). Éstos se definen 
como “aplicaciones avanzadas que, sin incluir la inteligencia 
como tal, proporcionan servicios innovadores en los modos de 
transporte y la gestión del tráfico y permiten a los distintos 
usuarios estar mejor informados y hacer un uso más seguro, 
más coordinado y “más inteligente” de las redes de transporte” 
[4]. El procedimiento sancionador electrónico presenta dos 
importantes similitudes con la definición anterior: ambas cues- 
tiones persiguen promover un uso más seguro de las carreteras 
y, además, buscan ofrecer una mejor información al conductor. 
En el caso del procedimiento sancionador, la información se 
refiere al estado de tramitación del procedimiento, cuestión 
que hasta el momento no ha sido resuelta de forma eficaz en 
el ámbito vehicular. 

El creciente desarrollo de los citados SIT ha dado origen 
a una arquitectura europea de referencia para estos servicios 
[5]. Ésta pretende ser el marco común en el que se puedan 
integrar todos los SIT que se diseñen en un lugar de Europa, 
asegurando que se pueda incorporar en cualquier otro país 
de la Unión. Uno de los servicios que se aborda en esta 
arquitectura es, precisamente, el procedimiento sancionador 
electrónico. Sin embargo, la funcionalidad prevista sobre este 
procedimiento se limita a la fase de iniciación. De hecho, la 
notificación de inicio de procedimiento no se envía a través de 
medios electrónicos. Dado que se aborda sólo una parte del 
procedimiento, se disminuye la eficacia y eficiencia esperables 
del uso de las tecnologías de la información. Por tanto, todavía 
es necesario proponer contribuciones que permitan realizar el 
procedimiento sancionador electrónico de forma completa. 


IV. PROPUESTA DE APLICACIÓN DEL PROCEDIMIENTO 
SANCIONADOR ELECTRÓNICO AL ÁMBITO DEL CONTROL 
DEL TRÁFICO 


El contexto vehicular está sufriendo una profunda transfor- 
mación, incorporando las tecnologías de la información en 
su funcionamiento rutinario. Así, el vehículo y el conductor 
pueden intercambiar información desde y hacia el exterior. En 
este trabajo se propone un modelo que abarque todas las fases 
del proceso sancionador aprovechando el desarrollo de las 
tecnologías de la información en este contexto. Dicho modelo 
se basa en el procedimiento sancionador descrito en la Sección 
II y extiende la funcionalidad prevista en la arquitectura de 
referencia SIT introducida en la Sección III 

El modelo que se propone tiene dos objetivos principales. 
El primero es alcanzar una comunicación directa con el 
interesado, permitiendo que el conductor tenga conocimiento 
inmediato del estado del procedimiento. El segundo es que el 
propio interesado pueda crear (y enviar a la Autoridad) pruebas 
electrónicas que sirvan de base para las alegaciones dentro de 
la fase de instrucción. Con ello se consigue que el interesado 
tengan una mayor capacidad de intervención en el proceso. 

En esta Sección se describe en primer lugar el modelo 
propuesto. En el segundo apartado se abordan sus necesidades 
de seguridad. Finalmente, el último apartado presenta un 
análisis preliminar de las técnicas de interés para desarrollar 
la arquitectura derivada de este modelo. 


IV-A. Descripción del modelo propuesto 


La Figura 2 refleja el modelo propuesto expresado con un 
diagrama de componentes UML que refleja los cuatro subsis- 
temas que se proponen para realizar el procedimiento sancio- 
nador electrónico. Cada subsistema aborda el procesamiento 
que efectúan cada una de las entidades o infraestructuras 
implicadas en el procedimiento, esto es, el testigo o testigos, la 
autoridad o autoridades, los interesados y las infraestructuras 
de comunicación. A continuación se explica cómo interviene 
cada uno de los componentes en el proceso resaltando las 
contribuciones que se realizan para llevar a cabo los objetivos 
planteados. 

El proceso comienza con la detección del comportamiento 
potencialmente sancionable. Para ello, el Registro de datos 
sensoriales del testigo muestrea el entorno en busca de ac- 
tuaciones ilegales. Cuando esto se produce, se emplea el 
componente de Acreditación y envío para que éste dote de 
legitimidad a los datos recogidos y se los comunique al 
organismo iniciador. Dicho envío se realiza a través de la 
Comunicación hacia la Autoridad y es recibido por su Registro 
electrónico. Gracias al registro, la solicitud pasa a formar 
parte de un nuevo expediente electrónico, de lo cual se deja 
constancia en la infraestructura de almacenamiento a través del 
componente Gestión de datos. El expediente creado se envía al 
componente de Iniciación, el cual evalúa lo sucedido y, en base 
a los antecedentes del infractor (si ha sido identificado) o del 
titular del vehículo (si el infractor real no ha sido identificado), 
establece una sanción y envía la notificación correspondiente. 


309 


Autoridad <<data secunity>> [adversary=detaul) 
<< provable>> (action=envío recepción) [cert=NRR,NRO) 
A A A O PA 1 
Iniciación Instruccion Resolución l 
de procedimiento de procedimiento de procedimiento 1 
Á I 1 1 Ú 
' ' A I 1 1 
! Ly 1 Lo 2 y 
AE l 13 $ Gestión de datos 
<<eriticab> 
in Registro de comunicaciones — — — —| (high=datos personales) 
| po eragros | 1 E 
1 + clon 
1 : 
1 im jura | | 
1 | comunicación <<data | | 
1 | securty»> [adversaryadetault : . 
np 7 a 
=p Comunicación Comunicación | dll 
Desdo Autoridad Hacia Autoridad 1] 
| L | 
1 A A Ú 
J 1 T | 
po= l | Testigo <<data secunty>> 
Interesado <<data security>> 1 1 (adversary «delault) ' 
[adversary=defauk) << provable>> 1 ' << provable>> ] 
(ectionzenvio recepción) (cert=NAR.NRO) 1 : 1 (ecton=envio).(certaNRO) 1 
a = B di T 
| 
| . : | 
I 
ol roo ooooo—- 3 Acreditación y envio 
y , ) ==>] 
Comunicación con Autoridad f- == — == <— Consulta estado de procedimiento Ú l 
1 SS ! A 
== == ! ' 1 
- il £ A | 
-— Registro datos sensoriales 
Procesamiento de notificaciones Y > Comunicación con testigo — — == — + e” 


Figura 2. Modelo propuesto de proceso sancionador electrónico en el ámbito del control del tráfico 


A diferencia de lo que ocurre en el modelo SIT de referencia 
(introducido en la Sección III), esta notificación se envía 
directamente a los interesados (entre ellos, el conductor sancio- 
nado). Dicho envío se efectúa a través del registro, quedando 
reflejado de nuevo en la infraestructura de almacenamiento. 
Para hacerlo llegar al interesado se emplea el componente de 
Comunicación desde la Autoridad. 

La notificación recibida es interpretada en el componen- 
te de Procesamiento de notificaciones, el cual informa al 
conductor y evalúa la conveniencia de construir las pruebas 
electrónicas que sustentarán las alegaciones. Los datos que se 
utilizan para elaborar dichas pruebas proceden de los datos 
sensoriales (posición, velocidad, dirección, etc.) percibidos 
por los testigos. Una vez preparada la alegación se envía al 
componente encargado de la Instrucción del procedimiento a 
través del componente de Comunicación hacia la Autoridad. 
Nuevamente, el Registro electrónico se encarga de atestiguar 
la recepción de las alegaciones y de incorporarlo al expediente 
electrónico. 

El componente de Instrucción del procedimiento valora 
entonces las alegaciones. En este punto, podría ser necesario 
realizar pruebas adicionales, como por ejemplo verificar el 
estado físico del registro de datos sensoriales del testigo ini- 
ciador del proceso. En ese caso, el proceso electrónico queda 
detenido a la espera de la necesaria intervención humana. En 
caso contrario, a la vista de las alegaciones se establece una 
propuesta de resolución, que es nuevamente enviada a los 
interesados del mismo modo que la anterior notificación. El 
vehículo, nuevamente, interpreta el mensaje recibido e informa 
al conductor, permitiendo que éste pueda conocer el estado del 
procedimiento de forma inmediata. 


El proceso finaliza con la Resolución del procedimiento. A 
diferencia de los pasos anteriores, este componente participa 


en el proceso sin que sea necesario que reciba un mensaje. Esta 
resolución establece la sanción definitiva, para lo que se debe 
valorar toda la información contenida en el expediente. En 
caso de que se hubieran realizado pruebas que interrumpieran 
la instrucción electrónica del procedimiento, esta fase no 
podría automatizarse, puesto que la valoración de una prueba 
tradicional no es computacionalmente alcanzable, al menos a 
corto plazo. En caso contrario, este procesamiento se efectúa 
de forma electrónica, enviando a los interesados la notificación 
resultante. Dicha notificación es finalmente interpretada y su 
contenido comunicado al conductor. 


IV-B. Análisis de seguridad del modelo propuesto 


Para que el modelo propuesto tenga cabida en el actual 
marco legal es necesario satisfacer, al menos, los requisitos de 
seguridad impuestos por la legislación aplicable (presentados 
en la Sección II). En esta Sección se describen las necesidades 
de seguridad que afectan a cada una de las partes del modelo 
propuesto. Estas necesidades se han incorporado, en la medida 
de lo posible, en la Figura 2 mediante la extensión UMLSec 
[6]. Adicionalmente, aquellas que no tenían cabida en dicha 
extensión se describen en el texto a continuación. Por claridad, 
se explicarán separadamente los requisitos que afectan a cada 
uno de los subsistemas que conforman el procedimiento: Au- 
toridad, Infraestructura de comunicación, Interesado y Testigo. 

Antes de comenzar la explicación, es necesario caracterizar 
al adversario frente al que hay que satisfacer las necesidades 
de seguridad. En el modelo actual se ha escogido el atacante 
definido por defecto en [6]. Dicho atacante es de tipo externo y 
puede borrar, leer e introducir mensajes en un canal inseguro, 
así como borrar datos de un canal cifrado. Este modelo de 
atacante es razonable para el modelo propuesto, pero debe 
ser adaptado y extendido en función de la arquitectura que se 
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derive posteriormente. 

IV-Bl. Subsistema Autoridad: Este subsistema necesita 
incorporar la seguridad adecuada para la tramitación del 
expediente electrónico. Debido a la naturaleza de los datos 
en juego, es necesario proteger su confidencialidad, lo cual 
se refleja con el estereotipo data security. Por otra parte, se 
debe evitar que en este subsistema se pueda negar que se 
envió o recibió una cierta información. Por este motivo, este 
subsistema tiene el estereotipo provable, que se aplica a ambas 
direcciones del intercambio de información. 

En lo que se refiere a necesidades específicas de algunos 
componentes, el de gestión de datos tiene el estereotipo critical 
dado que alberga todos los datos relativos a los expedientes. 
Dichos datos son, por su naturaleza, críticos para el proce- 
dimiento, por lo que deben extremarse las precauciones en 
cuanto a su preservacion. Por otra parte, el registro electrónico 
necesita asegurar su disponibilidad para estar permanentemen- 
te accesible. 

Finalmente, las dependencias existentes entre este subsis- 
tema y los restantes se han marcado con el estereotipo high, 
que refleja que los datos intercambiados son de naturaleza 
altamente sensible, por lo que deben eliminarse los riesgos 
de acceso, modificación y borrado no autorizados que puede 
realizar el atacante considerado. 

IV-B2. Subsistema Infraestructura de comunicación: Este 
subsistema ejerce de intermediario entre el subsistema Au- 
toridad y los demás subsistemas. Se trata por tanto de un 
subsistema crítico en el conjunto del proceso y por ello se 
exige su máxima disponibilidad. La transmisión que efectúe 
este subsistema debe proteger la información en los mismos 
términos en los que se exige en los demás subsistemas. Por 
este motivo, se impone a este subsistema el estereotipo data 
security. Debe notarse que éste impone, además, la confiden- 
cialidad, integridad, autenticidad y frescura de dichos datos. 
A diferencia de los demás subsistemas, éste no envía ninguna 
información por sí mismo, sino que sólo retransmite aquellas 
que recibe. Por este motivo, en este subsistema no se impone 
el estereotipo provable para la envío de los datos. Igualmente, 
tampoco se exige para su recepción, puesto que no es el 
destinatario final de ninguno de los mensajes intercambiados. 
Sin embargo, sí se exige la auditabilidad de su funcionamiento, 
a fin de poder verificar (a posteriori) la corrección de su 
funcionamiento. 

IV-B3. Subsistema Interesado: Este subsistema recibe los 
datos correspondientes al procedimiento y, en su caso, envía 
las alegaciones a la Autoridad. Dada la sensibilidad de la 
información en juego, este subsistema se ha marcado con el 
estereotipo data security. Además, debe quedar constancia de 
la fecha y hora en que se recibe y se procesa la notificación, 
pues este dato es relevante en el proceso sancionador, tal y 
como se expuso en la Sección II. Igualmente, no debe poderse 
negar el envío de las alegaciones. Ambas necesidades se 
reflejan con el estereotipo provable sobre ambos intercambios 
de información. 

Además de lo anterior, sobre este subsistema debe sa- 
tisfacerse el requisito de disponibilidad, pues puede recibir 


potencialmente numerosas notificaciones en un corto espacio 
de tiempo. 

IV-B4. Subsistema Testigo: Este subsistema necesita ase- 
gurar los datos que gestiona, pues contienen información 
de carácter personal (por ejemplo, la identidad del supuesto 
infractor). Esta necesidad justifica el uso del estereotipo data 
security. Por otro lado, el testigo no debe poder negar el envío 
de la solicitud de iniciación del procedimiento. Esto se refleja 
mediante el uso del estereotipo provable. 

La exigida autenticidad de los datos recogidos por el testigo 
se traduce en dos necesidades interrelacionadas. En primer 
lugar, los datos sensoriales recogidos deben ser veraces, es 
decir, reflejar fielmente la realidad. En segundo lugar, dichos 
datos deben estar referidos al comportamiento de un vehículo 
convenientemente identificado y autenticado. Esta última nece- 
sidad debe satisfacerse sin comprometer la debida privacidad 
de los conductores. Así, dicho componente, exclusivamente 
en el caso de que exista infracción, debe obtener el conjunto 
mínimo de datos para identificar al vehículo y, deseablemente, 
al conductor. De lo contrario, podría seguirse la trayectoría de 
un vehículo a lo largo de las carreteras. Dicho seguimiento 
constituye una violación de la debida privacidad del conductor 
incluso sí solo se identifica al vehículo, en tanto que habitual- 
mente existe una relación entre el vehículo y su conductor. 
Dicha relación permite que la identificación del vehículo se 
convierta, indirectamente, en la de su conductor [7]. 

Además de lo anterior, el testigo debe ser auditable, man- 
teniendo un registro de sus acciones que permita verificar 
su correcto funcionamiento. Finalmente, el testigo debe estar 
plenamente disponible, tratando de maximizar la cantidad de 
observaciones procesadas por unidad de tiempo. 


IV-C. Análisis preliminar de viabilidad técnica 


El modelo propuesto identifica las principales funciones que 
permiten abordar de manera electrónica el procedimiento san- 
cionador. Sin embargo, la implementación práctica de dichas 
funciones queda fuera del alcance del modelo. En esta Sección 
se introducen algunas tecnologías que pueden ser de interés 
para abordar esta implementación, satisfaciendo los requisitos 
de seguridad identificados en la Sección IV-B. Si bien el sub- 
sistema Autoridad puede desarrollarse utilizando técnicas de 
computación más tradicionales, los restantes parecen requerir 
un enfoque más innovador, pues se implementan en un entorno 
distribuido donde el vehículo cobra una mayor importancia. A 
continuación se explican las técnicas que se han identificado 
en primera instancia como relevantes para el futuro desarrollo 
del modelo. 

Para el desarrollo del subsistema de Infraestructura de 
comunicación, se pueden aprovechar las diversas tecnologías 
identificadas por el proyecto CVIS?. De entre estas, destacan 
las alternativas basadas en satélites y las que aprovechan los 
recientes desarrollos en materia de comunicación vehicular 
(redes VANET, introducidas en la Sección III). En esta última 
alternativa, se exige el despliegue de una infraestructura de 


2http://www.cvisproject.org/ 
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comunicación a lo largo de las carreteras denominada RSU 
(del inglés Road-Side Unit, unidad de comunicaciones longi- 
tudinal a la vía). Una de las principales ventajas de su uso es 
que se permite una comunicación directa y permanente con 
el vehículo, donde podría alojarse el subsistema Interesado. 
Para asegurar la conectividad, los vehículos se equiparían con 
los dispositivos OBU (del inglés On-Board Unit, unidad de 
comunicaciones a bordo). Este tipo de comunicación vehículo- 
infraestructura dispone de su propia norma acerca de la 
seguridad de las comunicaciones (IEEE 1609.2, [8]), la cual 
será de interés a la vista de los requisitos identificados en este 
trabajo. 

Con respecto al subsistema Interesado, se necesita disponer 
de una plataforma de computación que proteja tanto la in- 
formación en juego como la corrección de su procesamiento. 
A este respecto, los dispositivos HSM (del inglés Hardware 
Security Module, módulos de seguridad físicos) satisfacen las 
necesidades planteadas en el modelo [9]. 

Finalmente, con respecto al subsistema Testigo, resulta 
necesario disponer de técnicas confiables de percepción del 
entorno. Con este fin, los dispositivos EDR (del inglés Event 
Data Recorder, registrador de eventos) permiten registrar lo 
ocurrido en el entorno vehicular. Además, con el fin de poder 
incorporar en una visión única las percepciones de varios 
testigos, se pueden utilizar (o adaptar) protocolos que evalúan 
la credibilidad de cada uno de ellos [10]. Además, de cara a 
asegurar los propios sensores y la transmisión de información, 
pueden aprovecharse los mecanismos propuestos por proyectos 
de investigación, tales como OVERSEE?. 


V. TRABAJOS RELACIONADOS 


Las principales contribuciones técnicas relativas al procedi- 
miento sancionador electrónico en el ámbito del control del 
tráfico han buscado mejorar la recepción de información por 
parte del ciudadano. Así, en el caso de España se han imple- 
mentado las notificaciones telemáticas referidas al tráfico, en 
las que se envía un mensaje al teléfono móvil advirtiendo de 
la recepción de una notificación electrónica en la Dirección 
Electrónica Vial*. El modelo propuesto traspasa los límites de 
esta iniciativa, permitiendo que no sólo se reciba información 
sino que también se puedan aportar datos al procedimiento. 

Por otro lado, el procedimiento sancionador de tráfico se 
ha modificado recientemente en España [11]. Dicha reforma 
busca acortar los plazos de tramitación eliminando la fase de 
instrucción para aquellos conductores que accedan a pagar el 
importe de la sanción inicial. El modelo propuesto en este 
trabajo supera a dicha reforma, en tanto que conjuga de una 
manera razonable los intereses de ambas partes: la Administra- 
ción desea evitar que los procedimientos se alarguen, pero el 
ciudadano tiene derecho a defenderse en situación de igualdad 
probatoria. Para la creación de estas pruebas en el entorno 
vehicular, existen propuestas previas que pueden servir de 
base para el desarrollo de la arquitectura derivada del modelo 
presentado en este trabajo [12]. 


3https://www.oversee-project.com/index.php?id=9 
4http://www.det.es/portal/es/oficina_virtual/multas/notif_por_internet_movil/ 
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El procedimiento sancionador permite la imposición de 
castigos a aquellos ciudadanos cuyo comportamiento no sea 
acorde con la Ley. Sin embargo, su implementación actual 
sufre de una excesiva burocracia que redunda en una menor 
transparencia, eficacia y eficiencia. En este trabajo se ha des- 
crito el procedimiento sancionador y su realización electrónica 
según la legislación vigente. Partiendo de este marco, se ha 
propuesto un modelo para su aplicación en el ámbito del 
control del tráfico con especial atención a los aspectos de 
seguridad necesarios. Hasta donde se ha desarrollado esta 
investigación, esta es la primera propuesta que plantea la 
realización electrónica de todas las fases del procedimiento, 
lo cual constituye un punto de partida para su tramitación 
íntegramente automática. El modelo propuesto persigue fun- 
damentalmente incorporar dos características novedosas a las 
propuestas previas: alcanzar una comunicación directa con el 
interesado y permitir que éste pueda crear pruebas electrónicas 
que sirvan de base para las alegaciones. Con ello se persigue 
proporcionar un conocimiento inmediato del estado del proce- 
dimiento a los implicados y otorgarles una mayor capacidad 
de intervención en el proceso. 

Las líneas futuras de trabajo se centran en desarrollar una 
arquitectura derivada del modelo propuesto, tomando como 
base las técnicas que se han identificado de forma preliminar 
en este trabajo. 


CONCLUSIONES Y LÍNEAS FUTURAS 
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Resumen—Este trabajo analiza las amenazas derivadas de las 
malas prácticas en la gestión de técnicas SEO para indexación 
de páginas web, así como las vulnerabilidades y ataques que se 
pueden derivar de ellas. A partir de este análisis se ha propuesto 
un conjunto de cinco normas que deben resultar básicas para 
el desarrollo seguro de la gestión de indexación. Además, se ha 
propuesto la adaptación de estas normas al Esquema Nacional 
de Seguridad. 


I. INTRODUCCIÓN 


La correcta indexación de un sitio web por los motores de 
búsqueda reviste una importancia capital para contar con una 
presencia sólida en Internet. Con el fin de mejorar el posi- 
cionamiento de un sitio web en la página de resultados de un 
buscador se utilizan las denominadas técnicas de optimización 
para motores de búsqueda (Search Engine Optimization, SEO). 
Entre la gran variedad de técnicas SEO, se incluyen la correcta 
configuración de los archivos robots.txt [1] y de sitemap [2] 
para indicar a los buscadores qué indexar y qué no dentro 
de un sitio web. La incorrecta configuración de estos archivos 
puede acarrear consecuencias negativas desde el punto de vista 
de la seguridad y del rendimiento de un sitio web. 

El viernes 29 de enero de 2010 se publicó en el BOE el 
Real Decreto 3/2010, de 8 de enero, por el que se regula el 
Esquema Nacional de Seguridad (ENS) en el ámbito de la 
Administración Electrónica [3]. El ENS nace con el objetivo 
de crear las condiciones necesarias de confianza en el uso de 
los medios electrónicos en las relaciones de los ciudadanos 
con las Administraciones públicas. Se limita a establecer los 
principios básicos y requisitos mínimos que permiten una 
protección adecuada de la información y los servicios [4], en 
respuesta al Art. 42.2 de la Ley 11/2007, de 22 de junio, de 
acceso electrónico de los ciudadanos a los servicios públicos 
[5]. 

En el extenso Anexo IL, el ENS proporciona medidas de 
seguridad concretas estructuradas en tres grandes grupos (or- 
ganizativas, operacionales, de protección), los cuales pueden 
estar a su vez divididos en más subgrupos. Aunque existe una 
categoría destinada a la protección de servicios y aplicaciones 
web, no se tratan específicamente los posibles problemas de 
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seguridad derivados de una deficiente configuración de los 
archivos robots.txt y sitemaps o una inadecuada gestión del 
posicionamiento en buscadores. 

El objetivo de este trabajo es exponer estos problemas y pro- 
poner unas guías de buenas prácticas de cara a combatirlos, las 
cuales podrían añadirse o complementar las recomendaciones 
del ENS. 

El trabajo está estructurado de la siguiente forma: en la 
Sec. Il se realiza un modelado de amenazas sobre los riesgos 
derivados de la incorrecta indexación de páginas web; en 
la Sec. III se ofrecen una serie de recomendaciones para 
protegerse frente a los riesgos identificados; en la Sec. IV se 
adaptan estas recomendaciones al formato del ENS; la Sec. V 
concluye el trabajo. 


II. MODELADO DE AMENAZAS EN EL CONTEXTO DE LA 
INDEXACIÓN DE PÁGINAS WEB 


El modelado de amenazas ayuda a identificar amenazas, 
ataques, vulnerabilidades y contramedidas con el fin de mejo- 
rar la gestión de la seguridad de los sistemas de información. 
En las siguientes secciones se explican cuáles son las ame- 
nazas, vulnerabilidades y ataques a los que está expuesto un 
sitio web con una incorrecta configuración de los archivos 
robots.txt y de sitemap. 


Il-A. Amenazas derivadas de malas prácticas en la gestión 
de indexación 


Se entiende por amenaza el potencial de que un incidente, 
deliberado o no, comprometa los objetivos de seguridad de 
la organización [6]. Entre los objetivos de toda organización 
suelen figurar el salvaguardar la privacidad de la información 
sensible, así como asegurar un servicio rápido y de calidad. 
En las siguientes secciones se describe cómo estos objetivos 
pueden verse amenazados. 

IFAI. Revelación de información sensible sobre la organi- 
zación: Toda organización posee información sensible: datos 
de personas físicas y jurídicas, ya sean empleados, clientes o 
proveedores; datos de funcionamiento interno, sistemas y ser- 
vicios, como archivos de configuración, registros de actividad 
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y código fuente; etc. Esta información sensible puede revelarse 
de varias maneras indeseadas y a veces insospechadas. 

Il-Ala. Metadatos inadecuados en documentos públi- 
cos: La mayoría de software utilizado cotidianamente para 
generar documentos digitales de todo tipo realiza la adición 
automática de datos sobre los datos creados (metadatos), los 
cuales se adjuntan de forma más o menos visible a los propios 
documentos. Estos metadatos pueden revelar información co- 
mo nombres de personas, organizaciones, fechas de creación, 
histórico de alteraciones en el documento, rutas de acceso de 
archivos, dispositivos utilizados en su creación, coordenadas 
GPS, y un sinfín de datos adicionales. 

Il-Alb. Errores de sistemas: Todo software está sujeto 
a errores o condiciones excepcionales que pueden provocar 
el funcionamiento anormal de una aplicación. Cuando estas 
excepciones no se gestionan adecuadamente, pueden revelar 
información sobre el sistema: código fuente, rutas de acceso 
de archivos, tipo de servidores, versión de software instalado, 
nombres de usuario, cadenas de conexión a bases de datos, 
consultas SQL que muestran a su vez estructuras internas de 
tablas, etc. 

IT-Alc. Rutas de acceso: Aunque los archivos robots.txt 
y de sitemap están destinados a los robots de búsqueda, son 
públicos y cualquiera puede descargarlos. Pueden contener 
información sobre rutas de acceso, las cuales a su vez rev- 
elan qué tipo de software existe instalado y qué contenidos 
sensibles se desean ocultar. 

Il-Ald. Contenido de ficheros de configuración: El 
funcionamiento de algunos servidores se configura mediante 
archivos de texto, los cuales pueden contener información 
sensible como nombres de usuario y contraseñas, cadenas de 
conexión a bases de datos, rutas de acceso de archivos, etc. 

IIl-Ale. Contenido de ficheros de registro de actividad: 
Registrar en archivos de texto la actividad de un servidor 
permite estudiar de qué manera es usado y también reconstruir 
incidencias. Estos registros o logs pueden contener informa- 
ción sensible de los visitantes, como por ejemplo los datos 
introducidos en formularios. 

IF-AIf. Evidencias de intrusiones y vulnerabilidades: 
Hay ocasiones en que un ciberdelincuente consigue vulnerar 
la seguridad de un sitio web y modificar sus páginas y doc- 
umentos. El conocimiento público de este tipo de incidentes 
puede dañar seriamente la imagen y la credibilidad de las orga- 
nizaciones afectadas. Pero no acaban ahí las consecuencias: si 
los buscadores indexan y muestran páginas con evidencias de 
intrusiones o vulnerabilidades, otros ciberdelincuentes podrían 
aprovechar esta información para dirigir nuevos ataques contra 
la organización. 

IF-A2. Deterioro del rendimiento: Un objetivo fundamen- 
tal de todo servicio web es asegurar un buen rendimiento, 
percibido por los usuarios como la cantidad de tiempo nece- 
saria para cargar la página solicitada. Los motores de búsqueda 
legítimos por lo general obedecen el protocolo de exclusión 
de robots que indica qué porciones del sitio web deben 
agregarse a los resultados de búsqueda. Archivos robots.txt 
O sitemaps mal configurados pueden originar una sobrecarga 


de peticiones por parte de estos robots, causando una pérdida 
de rendimiento. 

IFAS. Deterioro de la calidad de servicio: A medida que 
se incrementa la complejidad de un sitio web y crece su 
número de páginas, resulta más difícil navegar por ellas y 
encontrar la información deseada. Un sitio web que carezca 
de una buena gestión de SEO perderá visibilidad, ya que 
no aparecerá entre los 10 primeros puestos en las páginas 
de resultados de los buscadores, y también calidad, porque 
aunque aparezca listado, no aparecerán en primer lugar las 
páginas más relevantes dentro del propio sitio. 

En última instancia, una gestión inadecuada de la seguridad 
y/o de las técnicas SEO pueden causar que el sitio web de 
la organización sea excluído completamente de las páginas 
de resultados de los buscadores. Esto puede ocurrir no sólo 
por una pobre promoción sino también en caso de que las 
organizaciones que gestionan los buscadores lleguen a la 
conclusión de que se utilizan técnicas ilegítimas o fraudulentas 
para mejorar el posicionamiento. 

I-A4. Secuestro de resultados de búsqueda: Para asegurar 
la visibilidad en Internet, es muy importante que la búsqueda 
de palabras relevantes para el servicio prestado por una orga- 
nización conduzca al sitio web de esta organización. Existen 
técnicas conocidas como Black Hat SEO [7] que pueden 
alterar artificialmente estos resultados. 


II-B. Vulnerabilidades en la gestión de indexación: Mala 
configuración de robots.txt y sitemaps 


Se entiende por vulnerabilidad toda debilidad en un sistema 
que podría permitir o facilitar la materialización de una 
amenaza contra un activo [6]. La forma de disminuir el riesgo 
a que se ven expuestos los activos de la organización pasa 
por mitigar o eliminar las vulnerabilidades. En las siguientes 
secciones se describen cuáles son las vulnerabilidades más 
importantes en la gestión de una política de SEO asociadas a 
los archivos robots.txt y sitemaps. 

IFB1. Inexistencia de archivos: Los robots de búsqueda 
podrían indexar absolutamente todo el contenido al que se ten- 
ga acceso públicamente navegando desde la página principal. 

II-B2. Archivos excesivamente explícitos: Algunos sitios 
web se sirven del archivo robots.txt para especificar los 
directorios o archivos con información sensible para evitar 
que sean indexados por los robots de búsqueda. Este archivo 
puede por tanto llegar a contener información sobre directorios 
y archivos confidenciales. 

IFB3. Archivos con errores: Un archivo robots.txt mal 
configurado puede suponer una sobrecarga para el servidor 
al permitir que los motores de búsqueda realicen peticiones 
innecesarias y entren en bucles. 

IF-B4. Archivos robots.txt y de sitemap mal configurados: 
Como parte de una estrategia de SEO global, deben configu- 
rarse adecuadamente estos archivos para garantizar una buena 
visibilidad en la página de resultados y una buena calidad en 
los enlaces mostrados en primer lugar. 
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User-agent: * 


Disallow: /administrator/ 
Disallow: /cache/ 
Disallow: /components/ 
Disallow: /editor/ 
Disallow: /includes/ 
Disallow: /mambots/ 
Disallow: /modules/ 
Disallow: /templates/ 
Disallow: /installation/ 


Figura 1. Ejemplo de archivo robots.txt con exceso de información. 


User-Agent: * 


Disallow: /etc 
Disallow: /bin 
Disallow: /tmp 
Disallow: /log 
Allow: / 


Figura 2. Ejemplo de archivo robots.txt con exceso de información. 


IF-B3. Archivos muy permisivos: Permiten que Google in- 
dexe todo tipo de páginas de configuración, manuales, ayudas 
y mensajes de error, los cuales son expuestos a través de 
búsquedas conocidas como “google dorks” [8]. 

IF-B6. Archivos mal protegidos: Si los archivos robots.txt 
y/o de sitemap pudieran ser modificados por un ciberdelin- 
cuente, éste podría controlar qué contenidos del sitio pueden 
ser indexados por los buscadores y cuáles no, comprometien- 
do la imagen pública de la organización y su relevancia y 
presencia efectiva en Internet. 

Por otro lado, si el ciberdelincuente estuviera en condiciones 
de alterar los documentos publicados en el sitio web, podría 
conseguir que la organización propietaria del mismo apareciera 
relacionada con términos o temáticas no apropiadas. También 
podría introducir elementos que pudieran ser considerados por 
los buscadores como propios de técnicas SEO ilegítimas o 
fraudulentas, con las penalizaciones que ello conllevaría para 
el posicionamiento de la web. 


II-C. Ataques 


Se entiende por ataque todo intento, exitoso o no, de atentar 
contra el buen funcionamiento del sistema con el consiguiente 
incumplimiento de los objetivos de la organización [6]. En las 
siguientes secciones se describen sin ánimo de exhaustividad 
algunos de los ataques más populares dirigidos contra sitios 
web con una pobre gestión de SEO, capaces de materializar 
las amenazas descritas en la Sec. ILA. 

IF-C1. Rutas de acceso: El archivo robots.txt de la Fig. 1 
contiene un exceso de información al revelar la zona de 
administración y el tipo de software usado, ya que la carpeta 
mambots, sumada al resto de carpetas, ofrece el panorama 
típico de Mambo [9]. Permitió descubrir el software y la ruta 
de administración para el ataque posterior. 

En la Fig. 2 se ofrece otro ejemplo de archivo robots.txt 
que revela directorios del servidor. 


Disallow: /educational_games/medicine/ 
dna_double_helix/xmldata.xml 


Figura 3. Fragmento de archivo robots.txt. 


11-C2. Metadatos: Debido a la mala manipulación de los 
archivos y a la indexación de Google es posible encontrar 
información sensible como, por ejemplo, cuentas de usuario 
con sencillas búsquedas como la siguiente: 

http: //www.google.com/thl=eséq= 
intitle:"Documents and Settings"site:es 
ministerio €lr=8aq=f80q= 
intitle:"Documents and Settings"site:es 
ministerio 

Existen herramientas como FOCA [10] que permiten au- 
tomatizar las tareas de localizar, descargar y analizar los 
documentos publicados en un sitio web en busca de datos 
relativos a usuarios, equipos, direcciones de correo electrónico, 
software y hardware utilizado, etc. 

IFC3. Ficheros de configuración: El archivo robots.txt 
de la Fig. 3 contiene numerosas líneas como la mostrada, 
en la que se revelan los nombres y rutas de archivos de 
configuración. En este caso, los archivos ocultados a los 
buscadores contienen las respuestas al juego propuesto por 
el sitio web. 

I1-C4. Revelación interna de datos: En principio, un bus- 
cador sólo indexa aquellos documentos a los que se puede 
acceder navegando a partir de la página inicial del dominio 
o que figuren en un fichero de sitemap aplicable. Así, si el 
documento A no está enlazado desde ningún otro documento 
del sitio web, no será indexado automáticamente por los 
buscadores. No obstante, si no existe un fichero robots.txt que 
prohíba la indexación de la ubicación del documento A, un 
atacante interno podría desvelar este fichero realizando una 
petición expresa de indexación al buscador con la ubicación 
exacta del documento A. 

II-C5. Alteración no autorizada de archivos: Un atacante 
que encontrara una vulnerabilidad en un sitio web podría in- 
tentar aprovecharla para modificar los contenidos y ficheros de 
configuración de dicho sitio. De tener éxito, podría ocasionar 
graves daños tanto a la imagen pública de la organización 
como a su posicionamiento en Internet. En particular, alterando 
los ficheros de sitemap y robots.txt podría controlar la forma 
en que se pide a los buscadores que indexen el sitio, exluyendo 
documentos relevantes e incluyendo otros con información 
sensible. 

No acaban ahí las posibilidades: algunos ciberdelincuentes 
trabajan para terceros que quieren mejorar el posicionamiento 
de sus sitios en los buscadores y, para conseguirlo, insertan 
enlaces a los mismos en las webs atacadas. Para evitar que 
estos enlaces sean detectados y eliminados por los webmasters, 
suelen hacer uso de diversas técnicas que hacen invisibles 
estos contenidos ante los visitantes humanos, normalmente 
relacionadas con la ejecución de scripts y el uso de hojas de 
estilo en cascada. 

Pero el uso de estas técnicas es considerado como fraudulen- 
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to por los buscadores, pudiendo ser causa de penalizaciones en 
el posicionamiento que, en último término, podrían acarrear la 
completa exclusión del sitio web de sus páginas de resultados. 

IF-C6. Indexación de URLs no apropiadas: La mayor 
parte de los buscadores disponen de servicios que permiten a 
sus usuarios solicitar la indexación de una página. Un atacante 
que descubriera una vulnerabilidad explotable a través de 
una URL podría solicitar la inclusión de la misma en las 
páginas de resultados, revelando públicamente la existencia 
de dicha vulnerabilidad. Además, los buscadores ejecutarían el 
correspondiente ataque cada vez que visitaran la página para 
actualizar sus índices. 

El mismo procedimiento podría ser utilizado para conseguir 
la indexación de otras URLs no apropiadas. 


TII.. BUENAS PRÁCTICAS EN LA GESTIÓN DE INDEXACIÓN 


El siguiente apartado recoge algunas de las buenas prácticas 
que deben ser aplicadas a la hora de exponer un sitio web a 
las arañas de los buscadores de Internet. Debe hacerse notar 
que, dado el carácter netamente dinámico del panorama de la 
Seguridad de la Información, no es posible garantizar un nivel 
absoluto de seguridad. Por ello, se proponen medidas orien- 
tadas tanto a que la información que los buscadores obtengan 
de la organización sea única y exclusivamente aquella que 
la organización desea, y su obtención sea efectiva, como a 
detectar y corregir cualquier impacto no deseado sobre el 
posicionamiento en buscadores y la presencia en Internet. 


IIFA. Por omisión: disallow:* para todos los robots 


La presencia o no de un sitio web en los buscadores de 
Internet debe ser una decisión de la organización a tomar en 
consideración con madurez. ¿Tiene sentido que estén indexa- 
dos los datos de una aplicación que utilizan sólo los empleados 
internos de una organización? ¿Tiene sentido que se indexen 
ficheros y datos privados de aplicaciones en la Intranet? En 
el caso que desee la organización tener presencia en los 
buscadores, ¿cómo quiere aparecer en ellos? Éstas y muchas 
preguntas deben ser contestadas con anterioridad a poner un 
sitio a disposición de las arañas de los buscadores. Si el sitio 
ha sido puesto en producción sin haber realizado la reflexión 
necesaria para conocer la presencia que se desea tener en 
ellos, debe configurarse un fichero robots.txt que bloquee la 
indexación de todos los contenidos de la organización. 

Debido al gran número de arañas de buscadores, es nece- 
sario realizar este bloque para todos los agentes: 

User-agent: * 

Disallow: / 

Este fichero indica a las arañas que no se desea ser in- 
dexado y no volverán a intentar indexar el sitio hasta que, 
manualmente, se pida su indexación. Si no se realiza esta 
configuración antes de poner el sitio en producción, los datos 
de la organización pueden estar copiados durante una cantidad 
incierta de tiempo en una gran cantidad de buscadores y será 
necesario realizar un borrado manual en todos ellos. 


User-agent: * 


Disallow: /cgi-bin/ 
Disallow: /images/ 
Disallow: /aplicaciones/ 


Figura 4. Ejemplo de un robots.txt para un sitio web. 


IHIFB. Auto-catalogación Si/No 


El siguiente paso consiste en realizar la clasificación que 
clarifique qué contenido debe o no ser indexado por los 
buscadores. Hay que tener en cuenta que debe ser indexado 
aquel contenido que sea estrictamente de índole público. 
En adelante se entiende por ruta pública la ubicación con 
contenidos que se desean indexar; y por ruta privada, la 
ubicación con contenidos que no se desea que sean copiados 
a los buscadores. 

Para realizar esta catalogación de una forma correcta se 
recomiendan las siguientes pautas: 


= Evitar rutas con contenido mixto (público/privado), ya 
que provocaría o fugas de información o mala presencia 
en Internet a la hora de decidir si una ruta es pública o 
privada. 

= Evitar contenido no enlazado en rutas públicas, pues 
alguien que lo descubra o conozca podrá solicitar su 
indexación manualmente. 

= Evitar rutas privadas conocidas, ya que ubicaciones 
privadas del tipo /etc o /home pueden identificar la 
existencia de archivos conocidos, sensibles a la seguridad 
de la información. 

= Evitar rutas privadas explícitas: Una catalogación co- 
mo privada de una ruta como /administrator oO 
/admin puede ayudar a un atacante a descubrir la exis- 
tencia de un fichero login.hml o login.jsp dentro de esas 
ubicaciones, debido a lo común de estas arquitecturas en 
aplicaciones web. 

= Evitar configuraciones privadas automáticas: ciertas apli- 
caciones web, como gestores documentales o gestores de 
contenido, utilizan ficheros robots.txt estándar que son 
fácilmente reconocidos. 

= Evitar el uso de rutas privadas a fichero: El pedir la no 
indexación de un fichero mediante el fichero robots.txt 
es hacer pública su ubicación, lo que es igual o más 
peligroso. Para restringir la indexación de una página 
única en rutas mixtas existen soluciones tecnológicas 
creadas para ello como es la meta etiqueta robots: 
<meta name="robots” content="“noindex”> 

= Aplicar la misma configuración para todas las arañas de 
todos los buscadores de Internet. 

= Proteger las rutas privadas con listas de control de acceso 
si es posible para evitar cualquier indexación por parte 
de los buscadores. 


HFC. Optimización del rendimiento y SEO con sitemaps 


Para optimizar tanto el consumo de recursos que realizan 
los robots dentro del sitio como la forma en la que un sitio 
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aparece en ellos se recomienda hacer un correcto uso de los 
archivos de sitemap. 

Este fichero, aunque es una modificación al estándar original 
del formato de robots.txt, es de aplicación extendida e indica 
a los robots de los buscadores tanto la importancia de los 
ficheros públicos, como su frecuencia de actualización. En 
sitios en los que se está indexando información estática con 
pocos cambios se puede configurar un largo periodo de actu- 
alización haciendo que el robot no intente indexar nuevamente 
los elementos. Además, en los sitemaps se marca también la 
fecha de la última actualización y si ésta es anterior a la fecha 
de indexación que tiene el buscador, no se volverán a realizar 
todas las peticiones de documentos. 

Usar los sitemaps correctamente ayuda a: 


1. Mejorar el rendimiento, aligerando la carga de los bots 
en el servidor web. 

2. Mejorar la presencia del sitio en Internet eligiendo cómo 
los usuarios deben encontrar y entrar en el sitio. 

3. Evitar los ataques de hijacking-SEO [7]. 


HI-D. Auditoría 


Una vez terminado de catalogarse correctamente el con- 
tenido entre público y privado, y tras optimizarse con sitemaps 
la carga de los robots y la relevancia del contenido, podría 
plantearse añadir el sitio a los buscadores mediante la sustitu- 
ción del archivo robots.txt inicial, que bloqueaba la indexación, 
por el nuevo archivo generado. Sin embargo, este proceso 
no debe realizarse hasta que el sitio web haya recibido una 
auditoría de seguridad, con el fin de que no se indexen posibles 
páginas de error como consecuencia de vulnerabilidades de 
Inyección de SQL o de Cross-Site Scripting (XSS). 

Además de la auditoría de seguridad, es altamente re- 
comendable realizar un análisis tanto del fichero robots.txt 
como de sitemap para comprobar que su funcionamiento va a 
ser el esperado. 

Una vez que se haya validado tanto la seguridad del sitio 
como el formato y la estructura de robots.txt y sitemaps, podrá 
ponerse en producción. 


HFE. Auditoría constante 


Debido a la estructura viva de muchos sitios web de Internet, 
es necesario incluir dentro de los procedimientos de auditoría 
la revisión de la presencia del sitio en Internet, mediante 
la reevaluación de robots.txt y sitemaps, como mediante la 
presencia de posibles fugas de datos en buscadores de Internet 
para, en caso de haberse producido, solicitar el borrado de la 
URL de los índices de los buscadores. 


TV. RECOMENDACIONES PARA ENS 


Es preciso determinar la forma en que un sistema establece 
un equilibrio entre la importancia de la información que 
maneja, los servicios que presta y el esfuerzo de seguridad 
requerido. Esto supone categorizar el sistema basándose en 
la valoración del impacto que tendría sobre la organización 
un incidente que afectara a la seguridad de la información 


o de los sistemas con repercusión en las funciones de dicha 
organización. 

Para poder mesurar el impacto de un incidente, en el 
ENS se proponen dimensiones de seguridad sobre las que 
posteriormente se podrán definir métricas de seguridad. Las 
dimensiones propuestas son: 

a) Disponibilidad (D) 

b) Autenticidad (A) 

c) Integridad (1) 

d) Confidencialidad (C) 

e) Trazabilidad (T) 

Cada uno de estos aspectos podrá evaluarse con tres posibles 
valores: BAJO, MEDIO y ALTO, según las definiciones del 
ENS [3]. 

Cuando un sistema maneja diferentes informaciones y presta 
diferentes servicios, el nivel del sistema en cada dimensión 
será el mayor de los establecidos. De esta forma es posible 
categorizar un sistema de información en tres categorías: 
BASICA, MEDIA y ALTA en función de que alguna de 
sus dimensiones esté evaluada en BAJO, MEDIO y ALTO, 
respectivamente. 

Una vez que se han definido las dimensiones de seguridad 
relevantes y la categoría del sistema a proteger, es posible 
elegir qué medidas de seguridad deben implementarse. La se- 
lección de las medidas de seguridad implicará la identificación 
de los tipos de activos presentes y la determinación de las 
dimensiones relevantes así como de su nivel correspondiente. 
Estas medidas pueden clasificarse en tres marcos diferencia- 
dos: el marco organizativo, el marco operacional y el marco de 
protección. Este último se centra en la protección de activos 
concretos, según su naturaleza y la calidad de servicio exigida. 

En el Esquema Nacional de Seguridad, a través del anexo Il, 
se propone un sistema tabulado para incluir todos los aspectos 
que pueden ser estimados como medidas de seguridad. Según 
se ha visto en las secciones anteriores, surge la necesidad 
de ampliar la propuesta de medidas de seguridad dentro del 
marco de protección con un bloque centrado en la protección 
de las técnicas SEO, en línea con el artículo 42 del ENS, en 
el que se indica que el esquema se debe mantener actualizado 
de manera permanente. Se desarrollará y perfeccionará a lo 
largo del tiempo, en paralelo al progreso de los servicios 
de Administración electrónica, de la evolución tecnológica y 
nuevos estándares internacionales de seguridad y auditoría. 

En la tabla IV se utilizan las siguientes convenciones: 

a) Para indicar que una determinada medida de seguridad 
se debe aplicar a una o varias dimensiones de seguridad 
en algún nivel determinado se utiliza “aplica”. 

b) «n.a. » significa “no aplica”. 

c) Para indicar que las exigencias de un nivel son iguales 
a las de un nivel anterior se utiliza el signo « = ». 

d) Para indicar el incremento de exigencias graduado en 
función del nivel de la dimensión de seguridad, se 
utilizan los signos « + » y « ++ ». 

e) Para indicar que una medida protege específicamente 
una cierta dimensión de seguridad, ésta se explicita 
mediante su inicial. 
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Dimensiones Medidas de seguridad 
Afectadas | BAJO | MEDIO | ALTO mp Medidas de protección 
mp.seo Protección de sitios web 
(6: aplica = = mp.seo.1 Valor por omisión:Disallow para todos los robots 
C,D aplica = = mp.seo.2 Auto-catalogación si/no 
D n.a aplica = mp.seo.3 | Optimización del rendimiento y SEO con sitemaps 
Categoría | aplica + ++ mp.seo.4 Auditoría 
Cuadro I 


CORRESPONDENCIA ENTRE LOS NIVELES DE SEGURIDAD EXIGIDOS EN CADA DIMENSIÓN Y LAS MEDIDAS DE SEGURIDAD 


IV-A. Valor por omisión de disallow para todos los robots 


Debido al gran número de arañas de buscadores, es nece- 
sario realizar este bloque para todos los agentes: 

User-agent: * 

Disallow: / 

Este fichero indica a las arañas que no se desea ser in- 
dexado y no volverán a intentar indexar el sitio hasta que, 
manualmente, se pida su indexación. Si no se realiza esta 
configuración antes de poner el sitio en producción, los datos 
de la organización pueden estar copiados durante una cantidad 
incierta de tiempo en una gran cantidad de buscadores y será 
necesario realizar un borrado manual en todos ellos. 


IV-B. Autocatalogación: SI/NO 


Los sistemas deben decidir qué contenidos son privados y 
cuales son públicos. A partir de esta clasificación es preciso 
determinar si las diferentes ubicaciones del servidor correspon- 
den a una ruta pública o a una ruta privada. 


IV-C. Optimización rendimiento y SEO con sitemaps 


Para asegurar un rendimiento óptimo del consumo de re- 
cursos por parte de los robots en un sitio se recomienda una 
configuración adecuada de los archivos de sitemap. Como 
resultado se consigue mejorar el rendimiento del sistema, 
mejorar la calidad de servicio y evitar los ataques de hijacking 
SEO. 


IV-D. Auditoría 


Además de las auditorías a las que deberían estar sujetas 
las aplicaciones informáticas ofertadas por el sitio es preciso 
realizar un análisis exhaustivo del fichero robots.txt así como 
de los ficheros de sitemap para validar el comportamiento del 
sistema y la estructura de estos archivos. 

Categoría Básica 

Antes de pasar a producción se comprobará el correcto 
funcionamiento del sistema. 


a) Se comprobará que se cumplen los criterios de seguridad 

) Se harán pruebas en un entorno aislado 
c) Las pruebas no se harán con datos reales. 

) Se diseñará un sistema de auditoría constante que con- 
temple la naturaleza dinámica de muchos sitios web de 
Internet y que se traduzca en una reevaluación de las 
configuraciones de robots y de sitemap. Para ello se 
deben revisar: 


a) Posibles fugas de datos en buscadores de Internet. 


b) Posibles asociaciones en los buscadores de térmi- 
nos O temáticas no adecuadas al sitio web. 

c) Posibles URLs que revelen la existencia de intru- 
siones o vulnerabilidades. 

d) Posibles resultados que no se desea que aparezcan 
en los buscadores. 

e) Solicitar el borrado de URLs no deseadas de los 
índices de los buscadores en su caso. 


Categoría Media 
Se realizarán las siguientes inspecciones previas a la entrada 
en producción: 


a) Análisis de vulnerabilidades. 
b) Pruebas de intrusión derivadas del uso del sistema de 
indexación. 


Categoría Alta 
Se debe contemplar la siguiente línea de actuaciones: 


a) Análisis de cumplimiento con la calidad de servicio. 
b) Análisis de rendimiento del sistema. 


V. CONCLUSIONES 


El posicionamiento en buscadores se ha convertido en un 
activo fundamental para la presencia de las organizaciones en 
Internet y, como tal, debe ser objeto de una adecuada gestión 
y protección. En este trabajo se ha propuesto un conjunto 
de buenas prácticas, adecuando su formulación al Esquema 
Nacional de Seguridad. En la redacción se ha optado por un 
enfoque más conciso de lo que es habitual en la propuesta 
inicial del ENS buscando una mejor aplicabilidad del mismo. 
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Resumen—El concepto de Inteligencia Ambiental (Aml, Am- 
bient Intelligence) se refiere a un entorno sensitivo, interactivo, 
interconectado, contextualizado, transparente, inteligente y que 
actúa sin la intervención humana. Este entorno está emparentado 
con la ubicuidad de los dispositivos de computación que le 
permiten, de una forma transparente, advertir los cambios de 
contexto y reaccionar conforme a ello, tomando la iniciativa 
de forma inteligente para satisfacer las necesidades humanas 
dentro de lo posible. La importancia de la seguridad, privacidad 
y requisitos de confiabilidad, así como la complejidad de estos 
retos se ve amplificada con el modelo de computación propuesto 
por la Aml. Desde la perspectiva de la ingeniería del software, el 
cambio hacia la Aml podría deberse a los mecanismos necesarios 
para satisfacer los requisitos del cambio del paradigma de objeto 
hacia el propio paradigma del agente. Los objetos proporcionan 
funcionalidades que pueden ser utilizadas, en cambio, los agentes 
saben cuándo y cómo utilizar las suyas de forma autónoma. El 
paradigma del agente es muy útil para la implementación de 
Aml, además argumentamos de forma similar que es la base para 
la ingeniería de estos sistemas, teniendo en cuenta la seguridad 
desde las primeras etapas en la construcción de los sistemas. 


I. INTRODUCCIÓN 


Tanto los portátiles, como las PDAs y los teléfonos móviles 
de tercera generación cuentan con algún tipo de conexión in- 
alámbrica que nos permite el acceso a diferentes redes de datos 
en cualquier momento y prácticamente en cualquier lugar en 
que nos encontremos. La evolución en tamaño y capacidades 
de estos dispositivos y de las comunicaciones inalámbricas 
han permitido la conexión permanente de los usuarios a la 
red. Este incremento en la movilidad se puede asemejar al 
que hubo años atrás desde el clásico ordenador de sobremesa 
al portátil y va acompañada de una rápida adaptación por 
parte de los usuarios a este nuevo modelo de comunicación. El 
siguiente paso sería ayudar a la gente a ser capaces de apreciar 
la existencia de otras máquinas [1]. Las expectativas para el 
nuevo software son que será capaz de manejar conceptos como 
la localización y percepción del contexto, personalización, 
adaptabilidad, crecimiento orgánico, movilidad y otras muchas 
características que imponen la necesidad de un software más 
completo con métodos de ingeniería del software y nuevos e 
innovadores lenguajes de modelado [3]. 

La Inteligencia Ambiental (AmlI) se centra en adaptar nue- 
stro entorno sensitivo a nuestras necesidades y responder de 
forma inteligente a los usuarios y a los cambios de contexto del 
propio entorno [4]. Se espera que los objetos que nos rodean 
en nuestra vida cotidiana actúen de manera autónoma sin 


necesidad de la intervención humana. Este tipo de ambientes 
y la computación ubicua están íntimamente relacionados, 
ya que se pretende proporcionar a las personas servicios y 
utilidades de forma transparente, sin que explícitamente lo 
soliciten. El paradigma del agente es muy prometedor para la 
implementación de sistemas complejos como los de comercio 
electrónico, tráfico aéreo, planificación de recursos corpora- 
tivos, etc. [5]. Inicialmente creado en el seno de la Inteligencia 
Artificial, la comunidad científica y los investigadores han 
encontrado otras áreas en las que explotar de forma fructífera 
el paradigma del agente. Como se defiende en [6], [9] este 
paradigma ha tenido un especial interés en la ingeniería del 
software, ya que cambia el paradigma de la orientación de 
objetos. Este cambio se basa en la apreciación del mundo co- 
mo una sociedad de elementos inteligentes llamados agentes, 
que tiene percepción y pueden decidir. Esta manera de ver el 
mundo se diferencia del de la orientación a objetos, ya que ve 
conceptualmente al mundo como una colección de objetos sin 
autonomía. 

Una de las debilidades de la Aml es la falta de modelos 
y prácticas de ingeniería del software que ayuden en el 
análisis de requisitos, diseño, verificación, testeo, etc. Hasta 
el momento la investigación en esta área está situada en sus 
primeras etapas, y la necesidad de metodologías de desarrollo 
viables está más que reconocida. Nosotros creemos que el 
paradigma del agente no es útil únicamente para los sistemas 
de Aml, sino que además en todas las fases del ciclo de 
desarrollo tiene una gran utilidad. Somos conscientes de las 
nuevas metodologías de la ingeniería del software orientadas a 
agentes, aún en dominios académicos, deben ser nuevamente 
revisadas para la ingeniería de la Aml. Si damos pie al análisis 
y diseño de tales sistemas por el uso del software dirigido 
por la ingeniería del software de agentes, tendríamos que 
obtener sistemas finales basados en agentes que sean robustos, 
escalables y suficientemente inteligentes para satisfacer las 
necesidades de los sistemas de Aml. 

El resto de este artículo está estructurado de la siguiente 
forma; la siguiente sección muestra la Aml como un sistema 
multidisciplinar complejo. La sección 3 muestra una revisión 
del paradigma de agente. La sección 4 introduce las investiga- 
ciones en las metodologías orientadas a agentes. La sección 5 
discute el potencial que el paradigma de agente podría tener 
para el desarrollo de entornos inteligentes robustos. En la 
sección 6 describimos la importancia de la seguridad desde sus 
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etapas iniciales y para terminar mostramos unas conclusiones 
en la sección 7. 


II. EL ASPECTO MULTIDISCIPLINAR DE LA AMI 


Estamos enfocando nuestros esfuerzos hacia un modelo de 
ambiente que es perceptivo, inteligente y activo, que a la vez 
incluye múltiples disciplinas para contribuir en la creación 
del escenario final. Un gran número de investigadores están 
interesados en este nuevo área, evidentemente con diferentes 
motivaciones y objetivos. En el resto de la presente sección, 
vamos a proporcionar una visión de la Aml y vamos a intentar 
capturar una variedad de disciplinas que son indispensables 
reunir para conseguir esta visión. 

Philips [10] tiene una visión de la Aml basada en tres 
elementos claves, 1) la ubicuidad, referente a los dispositivos 
interrelacionados con el entorno humano, 2) la transparencia 
de estos sistemas de computación, es decir, que están ocultos 
en un segundo plano, 3) y la inteligencia, ya que deben actuar 
en lugar de estar esperando los mandatos de los humanos. 

La visión de la Aml del MIT [11] presenta ciertas simil- 
itudes, de hecho, la ve como una integración discreta de la 
computación en nuestras vidas diarias. Estos medios de com- 
putación proporcionan información relevante a los humanos 
y realizan tareas cuando estos las necesitan. Estos ambientes 
realizarán las tareas apropiadas de una forma transparente, 
invisible e inteligente. Tradicionalmente, los ordenadores han 
trabajado como un mediador o mensajero que aparentemente 
está entre los humanos y el entorno. En la Aml, esta relación 
es reemplazada por una relación directa no perjudicial entre 
los humanos y el entorno en los que estén localizados. En 
resumen, la computación en la Aml deja de ser visible al 
usuario. 

La primera perspectiva de ordenadores invisibles fue dirigi- 
da por Weiser [12]. Esta visión suponía la existencia ubicua 
de computación y de comunicación en cualquier momento y 
en cualquier lugar. La Aml se centra en la inteligencia y la 
conciencia de la ubicuidad de los dispositivos interconectados, 
de forma que la computación comienza a tomar la iniciativa 
en nombre de los humanos. La ubicuidad de la computación 
es la base sobre la que se construyen la Aml, los términos 
computación ubicua, computación omnipresente, ambientes de 
computación y Aml son usadas ahora de forma intercambi- 
ables con algunas diferencias en el contexto y el énfasis. 

Actualmente la Aml está integrando dispositivos en el 
entorno en el que vivimos, diferenciándose así de la realidad 
virtual que lleva el mundo a los computadores [12]. Este 
hecho hace invisibles a los computadores, borrándolos de la 
conciencia humana. Evidentemente, para llegar a este punto, 
los ordenadores han tenido que adaptarse a las necesidades 
y características de los usuarios, en contraste con la escena 
tradicional en la que se suponía que el usuario se adaptaba a 
los sistemas de computación. Con la Aml, los artefactos encap- 
sulan de forma implícita el papel de mediador de computación. 
Los artefactos aparentan tener su propio carácter, autonomía e 
inteligencia, llegando a ser más agentes que objetos normales. 


Como consecuencia de todo esto, la Aml es un paradigma 
de naturaleza multidisciplinar [13]. La inteligencia distribuida 
es necesaria para cubrir este entorno inteligente, que ahora 
está compuesto de unidades de inteligencia distribuida a los 
que llamamos agentes. Se está diseñando nuevo hardware, 
necesario para que los dispositivos embebidos sean invisibles 
y se mimeticen con el entorno físico que los rodea. El sistema 
de Aml se sitúa en un entorno extremadamente dinámico 
y abierto a continuos cambios, estos cambios necesitan ser 
identificados e interpretados para satisfacer las necesidades de 
los usuarios. 

La invisibilidad de los computadores fue considerada por 
Weiser [12] como una de las más relevantes características 
tecnológicas. La interacción entre ser humano y ordenador es 
llevada a un nivel superior, la interacción entre el ser humano y 
el propio entorno [1]. Las nuevas ideas al diseñar la interacción 
humano-máquina se trasladan de una interacción explícita a 
una implícita [14]. La interacción implícita incluye la noción 
de entrada de datos implícita, conocida comúnmente como 
contexto [15]. 

La conciencia del contexto [16] [17] es una característica 
esencial que los sistemas de Aml han de tratar para actuar 
de una forma adaptativa e inteligente. Este contexto, que 
debería ser espacio-temporal, ambiental, personal y social, 
necesita ser analizado y razonado según [2]. El razonamiento 
del contexto necesita de un modelo de formalización que actúe 
como una base de conocimiento y permita inferir en un nivel 
de conocimiento superior. 

De los sistemas de Aml también se espera la habilidad de 
aprender y de mantener la pista del comportamiento histórico 
de la persona. De hecho la personalización del software es una 
de las líneas de investigación actuales con más actividad, sin 
embargo, deberíamos considerar si un sistema de Aml es útil 
si se comporta de la misma manera ante diferentes usuarios 
con diferentes características. La movilidad social de los seres 
humanos es otro aspecto importante que debe considerar una 
aplicación de Aml. Normalmente la gente desempeña más 
de un rol social, estos deberían de estar recogidos por la 
tecnología considerando su contexto social [18]. 

La Aml abarca muchos aspectos sociales que deberían ser 
estudiados y analizados antes de tener una aceptación social 
en la práctica. La ubicuidad de la computación podría tener 
cierto impacto negativo. La gente sentirá que pierde el control 
y que no debe confiar en la tecnología. De hecho, la gente ya 
ha perdido cierta privacidad con los sistemas de localización 
de los teléfonos móviles o el uso de las tarjetas de crédito. La 
computación en Aml se supone que controla varios aspectos 
de la vida diaria de las personas. Un principio esencial de 
esta perspectiva es que el humano no sienta que ha perdido el 
control, y permitirles configurar sus necesidades fácilmente, 
como podría ser a través de algunos patrones de privacidad. 
A pesar de todo, existen muchos dominios de interés práctico 
que pueden terminar beneficiando a los escenarios de Aml, en 
particular aquellos especializados en el cuidado de personas 
ancianas y en la ayuda a personas con problemas de demencia, 
en los que la Aml podría desempeñar el papel de cuidador. 
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TIIl. ELPARADIGMA DEL AGENTE 


La computación basada en agentes está tomando importan- 
cia como área de investigación. Este creciente interés está 
motivado por la necesidad del software de poder actuar sin 
intervención del usuario y que sea capaz de llevar a cabo el 
concepto de agencia. No es fácil dar una definición de agente, 
entre otros factores porque no existe un consenso acerca de 
las principales características que debería reunir un agente 
software. Una definición bastante aceptada por la comunidad 
la podemos encontrar en [7]: 


an agent is a computer system situated in some 
environment, and that is capable of autonomous 
action in this environment in order to meet its design 
objectives 

Por su naturaleza un agente tiene el control sobre su propio 
estado, su comportamiento y es capaz de obtener información 
del entorno. Estar dentro de un entorno y sentirlo implica la 
necesidad de que un agente pueda reaccionar a los cambios de 
contexto del mismo entorno. Entre las características clave que 
debemos encontrar en un agente encontramos: autonomía, pro- 
actividad, reactividad, localización, direccionalidad y habilidad 
social. 

La autonomía de un agente viene dada por el hecho de que 
este se comporte de forma independiente de acuerdo al estado 
que encapsula. La pro-actividad significa que el agente es 
capaz de tomar la iniciativa sin órdenes externas. Los agentes 
tienen objetivos y Operan para conseguirlos. Esta característica 
es bastante más compleja que actuar ante estímulos directos 
como es habitual en los objetos tradicionales. La localización, 
del inglés situatedness, se refiere a la habilidad de un agente de 
situarse en un entorno con más agentes, percibirlos y responder 
a los cambios que pueda haber. La direccionalidad, del inglés 
directedness, significa que un agente tiene un objetivo, este 
objetivo representa el razonamiento de las acciones que realiza 
el agente. Los agentes viven en sociedades con otros agentes 
de manera colaborativa o posiblemente competitiva. De hecho, 
los agentes tienen la habilidad social de interactuar con otros 
agentes. 

Como hemos mencionado anteriormente, un agente está 
diseñado para convivir en una sociedad de agentes. Un sis- 
tema multi-agente (multi-agent system, MAS) es un sistema 
compuesto por varios agentes que son capaces de alcanzar sus 
objetivos, difícilmente alcanzables individualmente. Un MAS 
podría ayudarnos a dividir un problema en componentes que 
sean capaces de interactuar y tratar con situaciones impredeci- 
bles como podría ocurrir en sistemas de Aml. 

Un MAS representa una forma natural de descentralización, 
donde hay agentes autónomos trabajando como nodos con su 
propio comportamiento y control. Cada uno de estos agentes 
ve el mundo desde su propia perspectiva y tiene sus propios 
objetivos e intenciones. Una de las ventajas de los MAS es el 
buen funcionamiento con sistemas complejos abiertos, y una 
escalabilidad creciente. Como paradigma de computación es 
bastante prometedor y nos permite implementar multitud de 
aplicaciones de diferentes dominios como comercio electróni- 


co, planificación de recursos corporativos, control de tráfico, 
etc. [5]. Por todo esto, vemos que un sistema de Aml encaja 
a la perfección con la naturaleza de los sistemas de agentes, 
tema que abordamos en mayor profundidad en las siguientes 
secciones. 


IV. INGENIERÍA DEL SOFTWARE ORIENTADA A AGENTES: 
AGENT ORIENTED SOFTWARE ENGINEERING (AOSE) 


La ingeniería del software difiere de las demás ingenierías 
por su fuerte dependencia a las habilidades que tenga el 
ingeniero a la hora de analizar el problema, diseñar una 
solución aceptable y realizar el sistema final [19]. A pesar 
de que, por naturaleza, la ingeniería del software es bastante 
cualitativa, constantemente se investiga en encontrar métodos 
científicos, modelos y criterios adecuados que ayuden en el 
desarrollo de software adecuado para alcanzar los objetivos. 

Muchos de los proyectos industriales han fracasado, debido 
a que el producto software final no realizaba lo que se esperaba 
de él. Los modelos usados para describir los requisitos y el 
diseño del software han de ser compactos y expresivos, con 
el objetivo de poder reemplazar, de manera eficaz, al lenguaje 
natural. Por lo tanto, los modelos necesitan ser suficientemente 
precisos, y deben mantener el significado de los conceptos 
reales que supuestamente representan. Estos modelos han de 
ser formales, de manera que podamos razonar sobre ellos 
y descubrir anomalías, inconsistencias O incoherencias. La 
metodología de la ingeniería del software debe por lo tanto 
proporcionar un nuevo proceso de creación de este tipo de 
modelos. 

Así como un agente observa constantemente el entorno, lo 
interpreta, actúa y se comunica con otros agentes, también 
representa un paradigma de computación muy prometedor 
para la implementación de sistemas complejos. Las AOSE 
intentan analizar y diseñar sistemas complejos para llegar 
a una implementación con agentes. Existen diversos grupos 
de investigación trabajando en el desarrollo de sus propias 
AOSE [9]. La orientación a agentes no implica que estas 
metodologías usen los conceptos de agencias ni las nociones 
abstractas de agentes en cada una de las fases de desarrollo de 
software, sino que, el objetivo consiste en analizar y diseñar 
la manera de obtener sistemas multi-agentes finales. Sólo 
Tropos [20], como AOSE, utiliza las nociones de agentes y 
la naturaleza de esta tecnología desde las primeras fases de 
análisis hasta las últimas, relacionadas con la implementación. 

Puesto que el uso de ordenadores se está convirtiendo de 
manera incremental en una parte esencial de las actividades 
diarias de los individuos, negocios y organizaciones, y que 
existe una necesidad de combinar rápidamente entre diferentes 
nodos y partes de computación, se hace crítico encontrar 
software dinámico, flexible, adaptable y localizado. De hecho, 
la necesidad de que el software evolucione crece más rápido 
que el proceso de desarrollo del software. La AOSE ha com- 
prendido esta necesidad, y está intentando crear métodos que 
permitan el desarrollo de un software resistente a la evolución 
de requisitos, un software que sea inteligente para adaptarse y 
cambiar fácilmente hacia nuevos entornos y requisitos. 
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Afortunadamente la AOSE no está restringida ni influen- 
ciada por ningún paradigma de computación ya creado. Esto 
si ocurrió con la orientación a objetos y el análisis y diseño 
estructurado [21] [22]. La disciplina de la AOSE crece al ritmo 
de la programación orientada a agentes y la infraestructura 
de agentes, lo cual podría cubrir el hueco existente entre el 
dominio de los problema y las soluciones. 


V. APROVECHANDO EL PARADIGMA DEL AGENTE EN EL 
DESARROLLO DE AMÍ 


El paradigma del agente encaja perfectamente en la imple- 
mentación de escenarios de Aml debido a las coincidencias 
entre las características del paradigma y las necesidades de 
la AmI. La abstracción del paradigma del agente contribuye 
al desarrollo de sistemas de Aml, incluyendo las fases de 
análisis y diseño, además de temas de seguridad. Proporcionar 
seguridad a un ecosistema de Aml lleva consigo satisfacer los 
requisitos de seguridad de los propietarios de los diferentes 
elementos como el hardware, el software y la información 
involucrada en los propios ecosistemas. Uno de los puntos 
más importantes es la falta de un modelo que pueda describir 
de manera apropiada este tipo de conjuntos de objetivos de 
seguridad y fiabilidad. Este hecho, junto con la capacidad 
de estas propuestas de ser extendidas y usadas en tiempo de 
ejecución con la ayuda de herramientas automáticas, mejora 
considerablemente uno de los aspectos más atractivos de la 
tecnología de agentes para los ecosistemas de Aml. En esta 
línea, el software de agentes pude ser la base para las nuevas 
soluciones de seguridad, como encontramos por ejemplo en 
la protección de contenidos [8] o la distribución de video 
streaming en multicast [40]. En esta sección vamos a plantear 
nuestra visión inicial de la orientación de agentes para la 
ingeniería y seguridad de la Aml. 


V-A. Desarrollo de Aml orientada a agentes 


Como explicábamos anteriormente, la AmI muestra un 
grado de complejidad que interrelaciona múltiples disciplinas 
y que requiere el uso de un paradigma de ingeniería especial. 
Esta necesidad viene de la nueva naturaleza de estos sistemas, 
donde el comportamiento no se conoce en detalle. La AmlI 
se distingue por su dinamismo, por ser abiertos y por inter- 
relacionarse con los componentes del entorno. Comparado con 
las prácticas de ingeniería del software orientada a objetos, el 
paradigma de agente ofrece un nivel superior de abstracción 
adecuado para sistemas complejos de ingeniería [23]. 

Podemos tratar la complejidad del desarrollo de software 
complejo a través de algunas técnicas como son la 1) De- 
scomposición del problema en subproblemas más pequeños 
fácilmente manejables. 2) El uso de modelos abstractos para 
representar sistemas centrados en algunos conceptos y rela- 
ciones, omitiendo otros que no están relacionados. Estos mod- 
elos deberán ser compactos y suficientemente expresivos para 
poder resumir de forma útil lo que expresamos en el lenguaje 
natural. 3) La definición y el manejo de interrelaciones entre 
componentes para resolver problemas mediante algún tipo de 
organización jerárquica [25]. 


Como se indica en [19], el paradigma del agente no es 
únicamente útil para la construcción del software sino que 
además se puede usar como una nueva forma de análisis 
y de diseño de sistemas complejos. Utilizando técnicas de 
abstracción, descomposición y organización para tratar la 
complejidad de estos sistemas, se puede seguir el paradigma 
del agente desde las fases más tempranas. Descomponer un 
sistema complejo en subsistemas relacionados, cada uno con 
su propio control de hebras y objetivos, puede verse como 
una sociedad de agentes que interactúan entre ellos. Los 
subsistemas se ven como agentes autónomos, la habilidad 
social del agente implica la interrelación a alto nivel entre los 
subsistemas. Esta interacción podría modelar la cooperación, 
coordinación o incluso la negociación entre los agentes. Como 
para una estructura de organización dinámica, el paradigma 
de agente tiene la expresividad de representar estos conceptos 
debido a su estructura explícita y mecanismos flexibles. Existe 
una metodología conocida con el nombre de Gaia [26] que fue 
desarrollada para reflejar esta idea proporcionando una forma 
metodológica para la ingeniería de algunos tipos de sistemas 
complejos. 

Para la ingeniería de Aml, como por ejemplo un campus in- 
teligente, necesitamos descomponer el sistema en subsistemas 
autónomos, y abstraer usando la conceptualización del nivel 
de conocimiento a un grano más fino que en la orientación 
a objetos que resulta útil para comportamientos predecibles 
y sistemas relativamente estáticos. Con Aml no hablamos 
de una organización con comportamiento conocido, proceso 
de negocio y un control directo. Aquí el ambiente está en 
continuo cambio y de formas impredecibles en muchos casos, 
de forma que necesitamos un alto grado de adaptabilidad para 
englobar todas las posibilidades que la Aml va a proporcionar 
en los escenarios de la vida diaria con multitud de alternativas. 
Sí consideramos la Aml como un sistema complejo abierto, 
creemos que el paradigma del agente puede contribuir en el 
análisis y el diseño de escenarios de Aml y no sólo en la 
implementación. 


V-B. 

Hasta el momento hemos mostrado que los sistemas basados 
en la tecnología de agentes pueden aportar importantes ben- 
eficios, especialmente en escenarios de aplicación distribuidos, 
autónomos, inteligentes o auto-organizados. Además del alto 
nivel de autonomía y la capacidad de auto-organización de los 
sistemas de agentes, estos proporcionan un soporte excelente 
para el desarrollo de sistemas en los que la fiabilidad es 
un requisito esencial, ya que encajan perfectamente en el 
perfil de software de monitorización. Tanto los escenarios de 
Aml como los de computación ubicua comparten este tipo de 
características, por lo que los sistemas de agentes son ideales 
para la aplicación en este tipo de entornos. Sin embargo, a 
pesar de la atención prestada a los agentes por parte de la 
comunidad investigadora, esta tecnología no ha conseguido 
ganar una gran aceptación, especialmente en la industria, y 
únicamente se ha aplicado en escenarios del mundo real muy 
concretos y escasos. Este hecho se produce, en gran medida 
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por la existencia de ciertos problemas de seguridad, que por 
otra parte son considerados los inconvenientes más urgentes a 
resolver, en esta tecnología, antes de que los agentes estén 
listos para ser usados de una forma extendida dentro del 
panorama industrial. En lo que respecta a la seguridad, los 
agentes presentan las soluciones más apropiadas puesto que 
engloban los requisitos de seguridad desde diferentes puntos 
de vista, con idea de conseguir los objetivos de cada parte 
de una forma colaborativa. Evidentemente, esta tecnología no 
estará suficientemente madura para ser usada hasta que se 
resuelvan los aspectos más importantes en lo que a seguridad 
respecta, tanto en encontrar los mecanismos apropiados, como 
en la aplicación de estos mecanismos. 

Tradicionalmente se han aplicado algunos de los mecanis- 
mos de protección genérica de software para la protección de 
sistemas de agentes. Sin embargo, las características especiales 
de esta tecnología obligan al uso de soluciones específicas. 
Algunos mecanismos de protección están orientados a la 
protección de los hosts del sistema frente a agentes con 
carácter malicioso. La solución más relevante para este prob- 
lema pensamos que viene por la utilización del concepto del 
Sandbox, consistente en un contenedor que limita o reduce 
el nivel de acceso que los agentes tienen y proporcionan 
ciertos mecanismos para controlar la interacción entre ellos. 
Otra técnica que trata esta vertiente del problema se conoce 
como proof carrying code (o código portador de prueba) [29], 
esta técnica se basa en que cada fragmento de código incluye 
una prueba detallada que se puede usar para determinar si la 
política de seguridad del host se satisface por parte del agente. 
Los hosts sólo tienen que verificar que la prueba es correcta 
(lo que significa que corresponde con el código) y que es 
compatible con la política de seguridad local, aunque hemos de 
mencionar que la aplicación de esta técnica no resulta sencilla, 
de hecho en multitud de ocasiones no es fácil encontrar estas 
políticas de seguridad. 

Otros mecanismos están orientados a la protección de los 
agentes frente a posibles agencias (hosts) maliciosas. La más 
representativa es la que se conoce como el uso de santu- 
arios [30], que consisten en entornos de ejecución en los 
que el agente móvil puede ejecutarse de forma segura. La 
mayoría de estas propuestas se construyen asumiendo que 
la plataforma donde se implementa el santuario es segura. 
Desgraciadamente, asumir esto no funciona en la práctica 
para los sistemas basados en agentes, puesto que no podemos 
basarnos en que todas las plataformas sean confiables. 

Por otro lado, se pueden aplicar varias técnicas para verificar 
la propia integridad. Esta idea resulta de utilidad para evitar 
que tanto el código como los datos del agente puedan ser 
manipulados de forma inadvertida. Dentro de este conjunto 
de técnicas anti-manipulación se incluyen otras como son las 
de cifrado, checksum, anti-depurado, anti-emulación, etc.[31], 
[32], que en definitiva comparten el mismo objetivo, pero 
que también están orientadas a la prevención del análisis 
de la función que implementa el propio agente. Todas estas 
técnicas presentan un grado de dificultad bastante alto en su 
aplicación, especialmente para los programadores que utilicen 


esta tecnología, principalmente debido al hecho de que la 
aplicación de estas técnicas implica ciertos conocimientos 
mínimos de seguridad. 

Una vez expuestas las diferentes alternativas, defendemos 
el hecho de que todas las técnicas descritas proporcionan 
protección a corto plazo, además de requerir una base de 
conocimiento mínima en temas de seguridad, por lo tanto, 
no son útiles para nuestro propósito. En cambio, en ciertos 
escenarios, pueden representar una solución bastante factible, 
especialmente combinada con otras soluciones. Existen algu- 
nas soluciones teóricas al problema, de hecho se ha demostra- 
do que la autoprotección de código no es viable, es decir, 
que no se puede asegurar la fiabilidad de una solución que 
sólo se base en software para la protección [36]. En algunos 
escenarios, la protección requerida está limitada a algunas 
partes del software (código o datos). De esta forma, la función 
implementada por el software o los datos han de estar ocultos 
para el host en el que se ejecute el software. Algunas de 
estas técnicas requieren un paso de procesamiento adicional 
externo para obtener los resultados deseados. Entre estos 
esquemas, las técnicas de ocultación permiten la evaluación 
de funciones cifradas [37]. Esta técnica se basa en proteger 
los datos procesados para la protección del propio agente. Por 
esta razón, es una técnica apropiada para la protección de los 
agentes. Sin embargo, sólo es aplicable para la protección de 
funciones polinomiales. 

El caso de los esquemas de colaboración en línea también es 
muy interesante. En estos esquemas, parte de la funcionalidad 
del software se ejecuta en uno o más computadores externos. 
La seguridad de esta solución depende de la imposibilidad de 
cada parte de identificar la función realizada por otros. Esta 
solución es muy apropiada para arquitecturas de computación 
distribuidas como son los sistemas basados en agentes o la 
computación grid. 

Por último, existen técnicas que crean una protección 
bidireccional, protegen tanto al agente como a la agencia. 
Entre ellas algunas se basan en el uso de soluciones basadas 
en hardware, como algunas que usan el Trusted Computing 
Platform como elemento base [39]. De hecho, con la reciente 
aparición de la computación ubicua, la necesidad de una 
plataforma segura se ha consolidado como un hecho evidente. 
Esta solución añade un componente confiable a la plataforma 
de computación, que normalmente consiste en cierto hardware 
integrado en la placa madre del ordenador y que se utiliza para 
crear confianza en los procesos software [38]. Otras técnicas 
se basan únicamente en elementos software, como por ejemplo 
la que hace uso de la computación protegida [40]. Esta técnica 
se basa en la partición de los elementos software en dos o más 
partes mutuamente dependientes, de forma que el código será 
ejecutado de forma remota por diferentes agentes. 


VI. CONCLUSIONES 


La Aml implican un salto desde las aplicaciones que 
proporcionan cierta funcionalidad y pueden ser utilizadas por 
una entidad externa, hacia aplicaciones que tienen su propia 
autonomía y saben exactamente como comportarse en entornos 
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humanos sin su interacción explícita. Desde un punto de vista 
abstracto, hemos descubierto las similitudes existentes entre 
las necesidades de Aml y las primitivas del paradigma del 
agente. En Aml, cada aplicación de ambiente se comportará 
como un agente que tiene personalidad y capacidad de de- 
cidir. Cada aplicación necesita ser autónoma, reaccionar a los 
cambios de entorno, y tomar la iniciativa para satisfacer las 
necesidades humanas de la forma correcta y en el momento 
adecuado. Las aplicaciones también necesitan incorporarse a 
un entorno abierto de otras aplicaciones y comunicarse con 
ellas, por lo que necesitan de algún tipo de habilidad social. 
Además, consideramos la Aml, que está enfocada a servir de 
forma impredecible en los escenarios de la vida diaria, como 
un sistema complejo abierto que necesita de ciertas labores 
de ingeniería que usan técnicas más avanzadas que las de los 
sistemas concretos y bien definidos. Defendemos la idea de 
que el paradigma del agente software es muy prometedor para 
el desarrollo de los sistemas de Aml durante todas las fases del 
ciclo de vida del desarrollo y no sólo en la implementación 
del mismo. Las metodologías de la ingeniería del software 
orientada a agentes tienen un gran potencial con respecto a la 
AmL, así que el siguiente paso podría ser adaptar metodologías 
existentes, O incluso crear alguna nueva, para hacer de la 
Aml una ingeniería en todas sus fases de desarrollo desde 
la recolección de requisitos hasta la implementación final. 
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Abstract—Los sistemas de detección de intrusiones de red o 
Network Intrusion Detection Systems (NIDS) son herramientas 
software o hardware que monitorizan el tráfico de red en busca 
de actividad maliciosa de distinta naturaleza. A medida que 
aparecen nuevas vulnerabilidades y métodos para explotarlas, 
estos sistemas son convenientemente actualizados. En caso de 
producirse, los ataques son detectados si un NIDS actualizado 
está monitorizando el sistema atacado, exceptuando aquellos 
ataques cuya firma aún no ha sido desarrollada (ataques de 
día cero). Esta situación ha provocado que los atacantes traten 
de desarrollar nuevas técnicas para pasar desapercibidos a ojos 
del NIDS cuando intentan atacar un sistema, o lo que es lo 
mismo, tratan de evadir su detección. Al igual que ocurre con las 
nuevas vulnerabilidades, los NIDS deben estar preparados para 
contrarrestar estas novedosas técnicas evasivas. Actualmente la 
mayoría de estas técnicas se basan en explotar ambigiiedades 
presentes en los protocolos de red, problema que fue presentado 
por Ptacek y Newsham [7]. En este artículo presentamos 
EVADIR, una nueva metodología que facilita la búsqueda de 
nuevas formas de evadir NIDS. El núcleo principal de la misma 
consiste en modelar el NIDS mediante Programación Genética 
(PG), haciendo uso de una sintaxis más sencilla que la del NIDS. 
De este modo, se facilita la búsqueda de técnicas evasivas sobre 
el detector al realizar el análisis sobre el modelo generado, cuya 
semántica es menos compleja que la del NIDS en cuestión. 


I. INTRODUCCIÓN 


Las tecnologías de la información se han convertido en 
un componente crítico de la economía actual. La protección 
de las mismas frente a acciones hostiles determinará, en 
gran medida, el desarrollo de la sociedad de la información 
y las comunicaciones. Las medidas de seguridad se suelen 
clasificar atendiendo a su forma de actuación en: de pre- 
vención, detección, corrección y recuperación. Aunque las más 
aconsejables de las anteriores son las primeras, el hecho de ser 
más costosas que las restantes, junto con la imposibilidad de 
anular completamente un riesgo, hace preferible distribuir los 
recursos entre todas las medidas citadas, dando lugar así a 
la llamada defensa perimetral, consistente en la construcción 
de sucesivas barreras de protección: preventivas, detectoras, 
correctivas y recuperadoras. 

Los sistemas de detección de intrusiones son herramientas 
software o hardware que automatizan el proceso de moni- 
torizar los eventos que acontecen en un ordenador o red en 
busca de evidencias de intrusiones [20]. Una intrusión se 
define como un intento de comprometer la confidencialidad, la 
integridad, o la disponibilidad de la información, o de soslayar 
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los mecanismos de seguridad de un ordenador o red. Los IDS 
de red o NIDS toman como fuente de información principal el 
tráfico de red. A este respecto, se define el concepto de evasión 
sobre un NIDS como aquella técnica que permite transformar 
un ataque definido y detectable en otra forma del mismo que lo 
soslaye. Es decir, el paquete o conjunto de paquetes (en caso 
que haya fragmentación o que el ataque se encapsule en una 
sesión entera) que contengan el ataque es modificado con el 
fin de que el NIDS no sea capaz de procesarlo adecuadamente, 
y por lo tanto, de detectarlo. 

Los NIDS son, junto con los cortafuegos, los primeros 
mecanismos de seguridad usados para proteger a los sistemas 
de información en red. En consecuencia son objetivos priori- 
tarios de los atacantes, que tratan de deshabilitarlos o forzarlos 
a producir información errónea. En general, los NIDS no 
proporcionan una respuesta automatizada a las intrusiones que 
detectan, y se precisa del análisis por parte de un administrador 
de seguridad de las alertas emitidas para determinar el alcance 
de las mismas y establecer qué medidas correctoras o recupe- 
radoras han de llevarse a cabo. Por este motivo, la información 
proporcionada por los NIDS, en caso de ser falsa, puede dar 
lugar a la distracción del personal de seguridad, como si de 
un señuelo se tratara [10]. 

Las técnicas de evasión propuestas hasta la fecha se basan, 
fundamentalmente, en el abuso de las ambigiedades existentes 
en los protocolos de comunicaciones. Dichas ambigitedades 
pueden provocar que los NIDS y los sistemas finales a proteger 
interpreten los protocolos de distinta forma, provocando que 
el procesamiento de las conexiones por parte de los NIDS y 
de los equipos finales sean diferentes. Esta situación favorece 
el diseño de ataques que evadan a los NIDS. 

La investigación en técnicas de evasión de NIDS basados 
en usos indebidos es, en conjunción con el descubrimiento 
y detección de nuevas formas de ataque, el principal modo 
de mejorar la eficacia de estos. En la actualidad, la rápida 
actualización de las firmas de los NIDS para la detección 
de nuevos ataques de red provoca que los atacantes traten 
de desarrollar técnicas evasivas, más sigilosas y difíciles de 
detectar. Así, un administrador de seguridad no es consciente 
de que el NIDS ha sido evadido hasta el posterior análisis 
forense de los sistemas comprometidos. Este contexto es la 
principal motivación de este trabajo, cuyo objetivo primordial 
es establecer una metodología que permita el descubrimiento 
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de nuevas formas de evadir NIDS y que, en consecuencia, 
favorezca el desarrollo de mecanismos en los NIDS para su 
prevención. 

Para la consecución de este objetivo, en la metodologia 
propuesta EVADIR (EVAsión de la Detección de Intrusiones 
en Red) se generan modelos (mediante PG) que tratan de 
emular el comportamiento de NIDS existentes con el fin de 
interpretar su modo de funcionamiento desde una perspectiva 
alternativa. Estos modelos, además de simplificar la comple- 
jidad de los NIDS, permiten modelar el comportamiento de 
NIDS de código cerrado, de los que se desconoce su modo 
de operación interno. Su análisis facilita el hallazgo de nuevas 
formas de evasión, difíciles de encontrar por otros medios. 
La aplicación práctica de esta metodología puede favorecer el 
diseño de NIDS más difíciles de evadir. 

El resto del artículo se estructura de la siguiente manera. En 
la sección II se presenta cual es el estado actual de la línea 
de investigación en las técnicas evasivas y el uso de PG en el 
ámbito de los NIDS. En la sección III se explica formalmente 
en qué consiste la metodología propuesta, así como las tareas 
que la componen. Finalmente, en la sección IV se establecen 
las conclusiones. 


II. ESTADO DE LA CUESTIÓN 


La evasión de NIDS fue tratada por primera vez por Ptacek 
y Newsham en 1998 [7]. En este artículo, los autores resaltan 
dos grandes problemas en el procesamiento del tráfico de 
red por parte de los NIDS. En primer lugar, un NIDS no 
siempre es capaz de conocer con exactitud la manera en que 
los paquetes serán procesados en el sistema final, debido a 
las ambigiiedades existentes en los protocolos TCP/IP. Por 
ejemplo, algunas implementaciones descartan los segmentos 
TCP cuyo campo checksum sea erróneo, pero otras no. Si 
el NIDS descarta un paquete con dicho campo erróneo, se 
expone a que el paquete sea procesado en el sistema final, y 
viceversa, puede procesar el paquete cuando en el sistema final 
no se procesaría. Un distinto procesamiento de los segmentos 
TCP puede conllevar que ciertos segmentos de un ataque no 
sean procesados (y por lo tanto detectados) por el NIDS, 
o puede darse que se procesen más paquetes de la cuenta, 
llegándose a un reensamblado distinto en los NIDS y en los 
sistemas monitorizados. El segundo problema presentado es 
que es posible realizar ataques de Denegación de Servicio 
(DoS) sobre los NIDS. Un envío de muchos paquetes mal 
construidos hacia un NIDS puede provocar que éste genere 
numerosas alertas, llegando incluso a no procesar algunos 
paquetes debido a la sobrecarga. Una atacante podría, antes 
de enviar los paquetes que componen un ataque, provocar esta 
situación, por lo que ésta sería la antesala del verdadero ataque 
que pasará inadvertido. 

Con el fin de explotar y estudiar las ambigiiedades men- 
cionadas anteriormente, se han diseñado algunas herramientas 
específicas, como Fragroute, la cual intercepta, modifica, y 
reescribe el tráfico destinado a un sistema [4], o IDSprobe, que 
genera tráfico modificado a partir de trazas originales [8]. Las 
modificaciones que estos sistemas proponen están orientadas 


a la generación de tráfico que provoque evasiones. De esta 
manera, se pueden realizar auditorías sobre NIDS haciendo 
uso de técnicas evasivas existentes. Alternativamente a estas 
herramientas, se pueden utilizar algunas funcionalidades de 
programas más conocidos como Nikto [13] o Nmap [12], 
cuyos parámetros de ejecución permiten modificar los paque- 
tes que se envían para intentar evitar la detección por parte de 
los NIDS. 

La literatura existente sobre técnicas que prevengan a los 
NIDS ante posibles evasiones se centra en el tratamiento 
del tráfico que le llega al NIDS, con el fin de paliar las 
ambigiedades en la interpretación de los protocolos de comu- 
nicaciones y establecer un procesamiento común. Watson et 
al. [1] proponen un sistema para depurar paquetes de datos, 
de manera que se eliminen los posibles intentos de evasión 
de los NIDS, e implementan un depurador (scrubber) sobre 
el protocolo TCP para generar tráfico bien formado a partir 
de uno de entrada que pueda contener ambigiledades. Por su 
parte, Handley et al., proponen el concepto de normalizadores 
de tráfico [9]. Éstos son elementos que se sitúan como inter- 
mediarios en la red y que toman el tráfico antes de que llegue 
al NIDS con el fin de eliminar las posibles ambigiiedades 
que puedan ocurrir. Dado que algunos de los problemas que 
pueden llevar a evasiones se dan en el reensamblado de los 
paquetes, estos normalizadores deben almacenar el estado y 
los paquetes previos de todas las conexiones entrantes, lo 
que requiere una gran capacidad de almacenamiento, ya que 
deben verificar la consistencia de los paquetes subsecuentes. 
Esta tarea consume una gran cantidad de recursos (tanto de 
procesamiento como de almacenamiento) y puede convertirse 
en un cuello de botella cuando se trabaja con redes de alta 
velocidad [2]. 

También se han propuesto algunas soluciones alternativas 
que no precisan de la modificación del tráfico. Varghese et. 
al. [3] plantean dividir la firma que busca el NIDS para 
detectar el ataque (NIDS signature) en pequeños fragmentos, 
de manera que cualquier paquete que contenga cualquiera 
de los fragmentos sería detectado de forma rápida, pasando 
después el conjunto de paquetes a un análisis más lento pero 
más profundo y por lo tanto más eficaz. Shankar y Paxson [5] 
proponen un sistema que notifica al NIDS la topología de red y 
el comportamiento (entendiéndose como tal la implementación 
de los protocolos) del sistema final que se monitoriza, de 
manera que pueda modificarse la configuración del NIDS para 
ajustarse a la información proporcionada por su sistema. A 
este respecto Snort [6], uno de los NIDS de código abierto 
más utilizado en la actualidad, implementa una técnica similar 
a esta en el preprocesador IP (frag3) de su última versión. 
Finalmente, Antichi et al. [11] proponen el uso de Bloom 
Filters, una suerte de filtros distribuidos que consiguen que 
la firma del NIDS sea detectada sin necesidad de un re- 
ensamblado previo de los paquetes. Con este sistema se mini- 
mizan los falsos negativos pero se incrementa sobremanera la 
carga computacional del NIDS. 

En lo referente a la búsqueda de evasiones en NIDS, 
cabe destacar el trabajo de Mutz et al. [27], en el cual 
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los autores proponen realizar ingeniería inversa (tomando un 
conjunto de entradas/salidas y analizando el comportamiento 
de los ficheros binarios de un NIDS comercial) con el fin 
de obtener información acerca de las firmas que aplican los 
NIDS cuyo comportamiento no es conocido al ser el código 
propietario. Una vez analizado su funcionamiento, los autores 
presentan un ejemplo de evasión con un ataque a servidores 
Apache. Su trabajo se centra en la evasión de las firmas, las 
cuales son el último escalón en la arquitectura de un NIDS, 
sin tener en consideración el preprocesamiento que pueda 
realizarse anteriormente. Sin embargo, las técnicas evasivas 
propuestas por Ptacek y Newsham [7] se basan precisamente 
en ambigiiedades de este preprocesamiento. 

La idea principal de nuestra propuesta, alternativa e inno- 
vadora frente a los antecedentes citados, consiste en desarrollar 
una metodología que facilite la búsqueda de técnicas de 
evasión de NIDS. Para la consecución de este objetivo se 
construirán modelos, que emulen el comportamiento de NIDS 
existentes. Para ello se utilizará programación genética [24], 
la cual se ha mostrado como un paradigma eficaz y eficiente 
de cara al desarrollo de NIDS [14], [15], [16], [17], [18], [19], 
lo que avala su utilización para el objetivo en cuestión. 


TI. EVADIR: METODOLOGÍA PARA LA EVASIÓN DE NIDS 


Este artículo tiene como objetivo principal la propuesta de 
una nueva metodología para buscar formas de evadir NIDS 
que permita predecir y prevenir futuros intentos de evasión. Se 
plantean las siguientes grandes tareas a cumplimentar dentro 
de la metodología (ver Figura 1): 


1) Generar un conjunto de datos que represente adecuada- 
mente la idiosincrasia del tráfico de red actual. Dicho 
tráfico incluirá tráfico normal y malicioso (incluyendo 
técnicas evasivas existentes). 

2) Definir y diseñar un sistema basado en Programación 
Genética que aborde el modelado automático de NIDS 
en producción y que proporcione una representación 
simplificada pero fiel de los mismos. 

3) Desarrollar nuevas técnicas evasivas analizando el mo- 
delo generado. 


A. Generación del tráfico y de los conjuntos de entrenamiento 
y test 


1) Preparación de la infraestructura virtual: En primer 
lugar se define la arquitectura lógica de red que se utilizará 
en el entorno de pruebas. Ésta ha de ser fiel a un entorno 
real para que el tráfico que se genere sea similar al que 
podríamos encontrar en los sistemas de información y las 
organizaciones. Dicha arquitectura (lógica) se compone una 
serie de equipos para la auditoría, para la instalación de los 
NIDS y para la máquina que hace las funciones de víctima. La 
arquitectura dispone además de un canal de comunicación que 
conecta las máquinas junto con uno o varios routers. Una vez 
definida la arquitectura lógica, se establece una arquitectura 
física haciendo uso de la técnica de virtualización [25] ya 
que ofrece una mayor flexibilidad y no requiere de una gran 
infraestructura física. El requisito aquí es disponer de equipos 


/ TA REA 3 > N 
Aplicación de técnicas de evasión 
existentes sobre el modelo 
Modificación de las técs. evasión 


Prueba y búsqueda de 
alternativas sobre el NIDS 


Fig. 1. Arquitectura de EVADIR. 


de gran potencia y almacenamiento con varias tarjetas de 
red que permitan realizar la simulación de la infraestructura. 
Como software de virtualización, se utiliza alguno de los 
existentes de código abierto, como VMWare o VirtualBox, 
ya que permite reducir costes y cumple con los requisitos 
necesarios en esta tarea. 

En esta fase, se instalan y configuran las máquinas virtuales 
usadas para la adquisición de datos. Han de instalarse tanto 
los Sistemas Operativos (varios, con el fin de trabajar con 
NIDS que funcionen sobre distintas plataformas) como el 
software necesario. La elección del S.O. y el software auxiliar 
a utilizar es una cuestión que debe definirse en el momento 
de implementar la metodología. 


2) Generación y etiquetado del tráfico: Haciendo uso del 
entorno virtual configurado, se genera tráfico variado, en- 
tendiéndose como tal el tráfico normal (es decir, simples 
conexiones TCP, UDP e IP sin actividad maliciosa), de ataque 
(los paquetes llevan encapsulados algún tipo de ataque, sobre 
todo de tipo HTTP) y evasivo (modificación los paquetes 
de ataque y normal haciendo uso de las técnicas de evasión 
existentes en la literatura, las cuales están implementadas y 
documentadas, [7]). La generación del tráfico se realiza de 
forma controlada, es decir, estableciendo de manera concisa 
qué paquetes se envían y filtrando la captura por la máquina 
auditora, de manera que se garantiza que el tráfico cumple con 
las características deseadas. Además, los datos se acompañan 
con una serie de metadatos para etiquetar y documentar las 
trazas generadas, ya que como se verá más adelante, este 
tráfico se utiliza en varias etapas de esta metodología. 

Para generar el tráfico, se hace uso de herramientas de 


327 


código abierto existentes que permiten el envío de segmentos 
TCP con la suficiente flexibilidad para modificar las cabeceras 
de los mismos y de los paquetes IP. De esta manera se 
pueden desarrollar las técnicas evasivas descritas por Ptacek y 
Newsham y generar así el tráfico evasivo. El contenido del 
tráfico enviado es algún ataque detectado en principio por 
cualquier NIDS (como por ejemplo, un ataque XSS sobre 
un servidor web) cuando se quiera generar tráfico de ataque, 
o simples peticiones HTTP no maliciosas cuando se quiera 
generar tráfico normal. Se ha decidido descartar la utilización 
de conjuntos de datos etiquetados públicamente disponibles 
en la literatura como LBNL [21] o KDD [22] debido a que 
el primero sólo incluye tráfico de reconocimiento (y además 
anonimizado) y el segundo data del año 1999 y su validez 
despierta controversia [23]. 

La generación del tráfico es una tarea crucial para la 
obtención de resultados útiles dentro de esta metodología, ya 
que va a determinar todos los procesos subsequentes como se 
verá más adelante. Debe por lo tanto garantizarse, mediante 
el análisis del tráfico generado, que todos los casos que se 
pretenden abordar están realmente reflejados en el tráfico, de 
lo contrario, ha de repetirse esta tarea hasta que los objetivos 
queden totalmente satisfechos. 

3) Exposición del tráfico a los NIDS: El tráfico generado se 
presenta de manera offline a los NIDS bajo estudio con el fin 
de obtener y registrar la salida que éstos dan. Es posible que 
parte del tráfico evasivo no sea detectado, por lo que se deben 
analizar las posibles evasiones que se produzcan. Es de esperar 
en esta fase que el tráfico normal pase desapercibido en las 
alertas de los NIDS, y que el tráfico malicioso sea detectado, 
lleve o no incluídas técnicas de evasión, ya que éstas están 
documentadas y existen herramientas que las tratan (e.g. Frag3 
de Snort). 

4) Procesamiento y extracción de características del 
tráfico: Hasta este punto lo que se ha obtenido es un conjunto 
de paquetes de tráfico sin tratar junto con la salida que los 
NIDS estudiados ofrecen cuando dicho tráfico se les presenta 
de manera offline. En este punto, se debe generar un conjunto 
de datos que relacione los paquetes de tráfico obtenidos con su 
correspondiente salida dada por cada NIDS. Dado que muchos 
NIDS trabajan a nivel de conexión y no de paquete, será 
necesario para esos casos constituir las conexiones presentes 
en el tráfico junto con la salida dada por el NIDS para esas 
conexiones. 

Debido al gran volumen de datos generado, para modelar 
NIDS se precisa de una fase de preprocesamiento de los datos, 
haciendo uso de técnicas de Minería de Datos (Data Mining) 
con el fin de tomar las características del tráfico más rele- 
vantes desde la perspectiva de la seguridad, constituyéndose 
posteriormente sendos conjuntos de entrenamiento y de test. 
El conjunto de datos está constituido por entradas como por 
ejemplo las que se muestran en la Figura 2. En esta figura, se 
pueden ver una serie de campos separados por comas, con 
2 etiquetas (los 2 últimos campos). Estas son, un símbolo 
para denotar si el paquete se corresponde con una actividad 
benigna (B en el ejemplo) o maliciosa (M en el ejemplo), y 


22,37273,54637,56676,5,0,0,0,1,1,0,58464,28642,0,M,+ 
37273,22,56676,54637,5,0,0,0,0,1,0,34800,52234,0,M 
22,2224,54113,20593,5,0,0,0,1,1,0,32760,44444,0,B,- 
1068,139,59831,24387,5,0,0,0,1,1,0,15376,64779,0,B,+ 
139,1068,24387,59831,5,0,0,0,1,1,0,17520,62547,0,B,- 
22,37273,54637,56676,5,0,0,0,1,1,0,58464,28482,0,M,+ 
37273,22,56676,54637,5,0,0,0,0,1,0,34800,52154,0,M,- 
22,37273,54637,56676,5,0,0,0,1,1,0,58464,28402,0,M,+ 
22,37273,54637,56676,5,0,0,0,1,1,0,58464,28322,0,M,+ 
22,2224,54113,20593,5,0,0,0,1,1,0,32760,44716,0,B,- 
22,2224,54113,20593,5,0,0,0,1,1,0,32760,44580,0,B,- 
1417,1103,61855,25411,5,0,0,0,0,1,0,17010,53159,0,B,- 
2224,22,20593,54113,5,0,0,0,1,1,0,17460,59804,0,B,+ 
1103,1417,25411,61855,5,0,0,0,1,1,0,64450,5683,0,B,- 
2224,22,20593,54113,5,0,0,0,1,1,0,17400,59728,0,B,- 


Fig. 2. Ejemplo de trazas que se obtendrán como conjuntos de entrenamiento 
y test 


otro símbolo que denota si el NIDS ha acertado o no en la 
predicción (en el ejemplo, - indica que lo etiqueta bien, y + 
que lo etiqueta mal). 


B. Modelado de los NIDS 


1) Análisis y diseño de la arquitectura de la Programación 
Genética: Primero se determinan cuales son los elementos 
terminales, operadores, función de fitness, parámetros de eje- 
cución del algoritmo, profundidad máxima del árbol, etc. 
Los operadores y terminales determinan la semántica de los 
modelos generados, por lo que se eligen de forma que faciliten 
la consecución del objetivo principal establecido, esto es, con 
el fin de obtener un modelo fácil de interpretar que permita 
la búsqueda de evasiones sobre él. Para la obtención de los 
valores óptimos de los parámetros del algoritmo se utiliza la 
técnica de validación cruzada [26]. El funcionamiento es el 
siguiente: 

1) Dividir el conjunto de entrenamiento en k hojas. 

2) Establecer aleatoriamente unos valores para los 
parámetros que se deseen configurar. Se recomienda 
acotar dichos valores para facilitar el proceso de 
búsqueda (por ejemplo, no se debería permitir que el 


valor del número de generaciones fuera menor de 10). 
3) Para cada k 


+. Generar un fichero que contenga todas las trazas 
menos la de la hoja k. 
+ Entrenar con ese fichero. 
+. Testear con el fichero que contenga las trazas de la 
hoja k. 
4) Almacenar las medias de los resultados de test. 
5) Volver al paso 2. Este proceso se repetirá al menos 4n 
veces, donde n es el número de parámetros a configurar, 
para asegurarse una buena variabilidad. 


Una vez finalizada la ejecución, se obtiene la configuración de 
parámetros que mejor resultados haya dado para utilizarla en 
la búqueda del modelo. La función de fitness en un principio 
será el error de clasificación, ya que no tiene sentido hablar de 
tasas de falsos positivos o negativos al tratarse de un modelado 


328 


del comportamiento de un NIDS, no de una detección real de 
ataques. Sin embargo, esta función podrá ser cualquier otra 
que se estime oportuno. 

2) Implementación de la búsqueda del mejor modelo: 
En esta fase se busca el individuo (mediante PG con los 
parámetros determinados en B.1) que mejor emula a cada 
NIDS sobre el conjunto de entrenamiento. Los resultados 
obtenidos sobre el conjunto de test determinan si es necesario 
redefinir el diseño para obtener un mejor individuo. Es posible 
por lo tanto que esta tarea y la anterior estén correlacionadas, 
es decir, en el momento de analizar los resultados, si se 
observa que no son los esperados o deseados, es necesario 
que redefinir la arquitectura de PG, estableciendo nuevos 
parámetros, generando nuevos operadores o redefinendo la 
función de fitness. 

3) Poda y preparación del modelo: En esta fase, se realiza 
una optimización manual del modelo para ajustarlo a una 
semántica de interpretación sencilla por parte de un humano. 
Esto es, el árbol generado mediante PG puede no ser sencillo 
de interpretar, puede usar nomenclaturas complejas, o quizás 
tenga nodos o incluso ramas enteras redundantes. 


C. Análisis y estudio de técnicas de evasión 


1) Aplicación de técnicas de evasión existentes: Se aplican 
las técnicas de evasión existentes en los paquetes de ataque 
para presentárselo al modelo generado y así poder observar 
su salida. Esto permite saber si el modelo es capaz o no 
de detectar los ataques cuando éstos han sido modificados 
para intentar evadir a los NIDS. El comportamiento observado 
se compara con el que había dado el NIDS original, para 
ver si realmente este modelo es fiel a su comportamiento. 
En esta fase se podrán extraer conclusiones acerca de qué 
técnicas evasivas no funcionan sobre el NIDS original y sí 
sobre el modelo generado, lo cual no es de mucha ayuda al 
ser este modelo en principio inexacto (es decir, no se comporta 
exactamente igual al NIDS). Sin embargo, si se diera alguna 
evasión en el NIDS original pero no sobre el modelo generado, 
podrían extraerse conclusión acerca del porqué el NIDS falla, 
y por lo tanto se podría ofrecer una solución. 

2) Modificación de las técnicas de evasión existentes: 
Una vez estudiado el comportamiento del modelo ante las 
técnicas evasivas, se buscan otras nuevas para evadirlo. Esto 
se hace modificando las técnicas evasivas originales con el fin 
de buscar una manera distinta pero relacionada que, aplicadas 
sobre el modelo generado, provoquen que éste no sea capaz 
de detectar el ataque. 

Es en esta tarea donde se corrobora la utilidad de mode- 
lar los NIDS, ya que los modelos generados nos permiten, 
mediante una sintaxis más sencilla y definida previamente, 
analizar el comportamiento que éstos tienen sin tener que 
entrar en los detalles internos de su implementación. Estos 
detalles, como se ha comentado previamente, pueden ser 
demasiado complejos y en muchos casos inaccesibles (cuando 
el código no sea abierto), por lo que la búsqueda de técnicas 
evasivas se convertiría en una tarea similar a la fuerza bruta. 


Sin embargo, utilizando los modelos obtenidos, esta tarea se 
realiza de una forma más sencilla y eficaz. 

3) Prueba de las técnicas modificadas sobre el NIDS 
original y búsqueda de alternativas: Aquellas técnicas de 
evasión modificadas que realmente evadan el modelo generado 
son aplicadas al NIDS original con el fin de estudiar si las 
modificaciones han provocado también la evasión en éste. 
Es de esperar que, si el comportamiento del modelo es 
suficientemente parecido al del NIDS, aquellas evasiones que 
sean exitosas sobre el modelo lo sean también sobre el NIDS. 

Hasta este punto de la metodología las evasiones probadas 
se basan en técnicas existentes o modificaciones de ellas. 
En este punto se van a probar nuevas técnicas, de distinta 
naturaleza, que, basándose en la semántica menos compleja 
del modelo evadan tanto al modelo como al NIDS (lo cual 
es el objetivo prioritario). Esta parte de la metodología es la 
menos automatizada, y la más estocástica, ya que, en función 
de la calidad del modelo, y aplicando la filosofía de prueba 
y error, encontrar nuevas evasiones puede no ser una tarea 
sencilla. Para poder encontrar nuevas técnicas, es necesario 
un conocimiento exhaustivo tanto del comportamiento del 
modelo (el cual lo ofrece el propio modelo) como del compor- 
tamiento de los protocolos de red (el cual está documentado 
y estudiado), por lo que es en esta parte en la cual el 
investigador ha de poner una mayor atención, ya que el resto 
de la metodología es un proceso automatizado que, una vez 
definido, es fácilmente replicable. 

En la Figura 3 se puede observar un diagrama general del 
flujo de información en EVADIR. Como se puede observar, el 
proceso de búsqueda de evasiones se realiza primero sobre el 
modelo generado, y una vez que se encuentran técnicas para 
evadirlo, éstas se aplican sobre el NIDS original para evaluar 
su comportamiento. 


IV. CONCLUSIÓN 


En los últimos años la complejidad de las Tecnologías de 
la Información se ha visto severamente incrementada. Esta 
complejidad hace que los sistemas requieran cada vez más 
de técnicas que garanticen su seguridad. Los Sistemas de 
Detección de Intrusiones de Red (NIDS) basados en usos 
indebidos son herramientas que detectan posibles intrusiones 
en un sistema, basándose en ataques conocidos y para los 
que están preparados. Cada vez que se publica un nuevo 
ataque, los administradores actualizan las firmas de sus NIDS 
para que sean capaces de detectar ese ataque. Esta situación 
provoca que los atacantes busquen nuevas técnicas para evitar 
ser detectados cuando pretenden comprometer un sistema. Los 
NIDS basados en la detección de usos indebidos detectan 
cualquier ataque para el que estén configurados siempre y 
cuando sean capaces de procesar los paquetes que encapsulan 
dicho ataque. Sin embargo, existe la posibilidad de evadir 
este procesamiento [7]. En este artículo se ha presentado 
una metodología que automatiza el proceso de buscar nuevas 
técnicas evasivas mediante el modelado del comportamiento 
de los NIDS a través de técnicas de Programación Genética. 
Los modelos generados tienen una semántica más sencilla 
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Fig. 3. Diagrama de flujo de información en EVADIR 


que los NIDS, por lo que sobre estos modelos es más fácil 
buscar técnicas evasivas. Á este respecto, cabe destacar que 
los NIDS propietarios no publican su código y por lo tanto 
no es sencillo conocer su funcionamiento interno [27], por 
lo que un modelado del mismo es adecuado para el estudio 
de su comportamiento. Es de suponer que, siempre y cuando 
el proceso de modelado se haya realizado de una manera 
correcta, las técnicas evasivas que funcionen sobre el modelo 
también lo hacen sobre el NIDS original. 


Hasta la fecha hemos realizado pruebas de concepto sobre 
un NIDS basado en un árbol de decisión, haciendo uso de un 
escenario en el que hay presente tanto tráfico normal como 
tráfico malicioso (concretamente, escaneos de puertos). Los 
resultados de la prueba son fructíferos, ya que se han logrado 
encontrar algunas técnicas evasivas novedosas. Actualmente 
estamos aplicando esta metodología sobre NIDS reales, tanto 
de código abierto como propietarios. Como trabajo futuro 
se automatizará el proceso de buscar evasiones sobre los 
modelos (actualmente las evasiones son buscadas analizando 
la semántica del modelo producido manualmente), para lo cual 
se hace necesario establecer un formato común de la sintaxis 
que utilizan éstos modelos. 
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Abstract—A high-clock-rate free-space quantum key distribu- 
tion (QKD) system at a wavelength of 850 nm is presented. The 
system is designed to securely transmit cryptographic keys at 
high transmission rates between two locations in urban areas. 
The pointing, acquisition and active tracking of the QKD system 
are also presented. 


Keywords-Quantum key distribution, quantum cryptography, 
optical data communications, optical fibre, free space communi- 
cations, data encryption. 


IT. INTRODUCTION 


The need for alternative approaches to ensure worldwide 
data protection has become a priority during the last two 
decades, since increasingly more sensitive information is ex- 
changed and more users are involved. In this sense Quantum 
Information represents a new paradigm in the Information 
Age, where quantum properties such as the Heisenberg Un- 
certainty Principle, the No-Cloning Theorem or Entanglement 
have become the cornerstone in information security. Likewise 
the advances in quantum computing [1][2] consolidate the idea 
of future powerful quantum computers capable of superfast 
parallel computation, jeopardising classical methods or pro- 
tecting cryptographic keys based on public key cryptosystems. 
In this scenario quantum cryptography [3] is taking an increas- 
ingly important role, as 1t allows secure transmission of keys 
even against a quantum computer attack. Moreover, a quantum 
computer attack would have a retrospective effect, making data 
protected in the past also vulnerable. In this sense quantum 
cryptography should not be considered only as a technology 
for the future, but also a technology to ensure the secrecy of 
information encrypted today that we wish to maintain secret 
in the future. Although quantum keys have been transmitted 
at considerable distances such as 200 km [4] and 144 km 
[5] using fibre optic and free space links respectively, the 
key exchange rates of these links are still prohibitive low. 
Therefore the crucial challenge remains the distribution of 
keys at high speeds for Quantum Key Distribution (QKD) 
to represent a real and efficient alternative to classical key 
distribution systems. 

Another challenge arises from the impossibility of using 
quantum repeaters, since a fully functional practical quantum 
repeater [6] is still beyond current technology and the del- 
icate quantum states encoding the key would be perturbed. 
Therefore to habilitate key exchange among users located 


arbitrary on the globe, satellite-based links have been studied. 
In this sense research on free-space QKD systems has been 
especially focused on increasing the transmission distance of 
the free-space links in locations situated far from urban areas, 
designed to emulate satellite-to-earth links [7]. However, much 
less attention has been paid to short-distance high-transmission 
rate QKD systems for urban areas. 

Nowadays metropolitan fiber-optic networks suffer from the 
so-called "connectivity bottleneck”, referred to an imbalance 
located in many parts of the network caused by requirements 
of flexibility and cost effectiveness of service provisioning. 
Possibly the most viable alternative for addressing this band- 
width shortage is Free-Space Optics (ESO) [8]. Compared to 
fiber optic, FSO provides more flexibility and ease of de- 
ployment in multiple architectures, and therefore an economic 
advantage over optical fibre. Applied to QKD, FSO offers 
the possibility to establish not only earth-satellite but also 
high-rate short links. As mentioned above, the first option 
would allow global implementation of QKD whereas the 
second would enable high bit rate secure communication in 
metropolitan networks with a high-bandwidth demand. This 
would be attractive for commercial and financial buildings 
that wish to be connected to the backbone network. Therefore 
the development of short-range high bit rate QKD systems in 
urban areas is an increasing demand. 

We are building a GHz-clocked free-space QKD system 
that implements the B92 protocol [9]. This protocol uses only 
two non-orthogonal states of a quantum system as opposed to 
four, like in the BB84 protocol, since two states are enough 
to implement secure QKD. In practice, these two states can 
be two linearly polarised states at a nonorthogonal angle, 
as it is implemented in our system. Alice then, encodes the 
binary levels ”1” and *0” in the two polarised states, and sends 
them to Bob. When the receiver performs projections onto 
subspaces orthogonal to the signal states, he can measure 
the bits with certainty at the expense of some loss. This 
loss is the effect of the Heisenberg Uncertainty Principle, as 
nonorthogonal states cannot be distinguished unambiguously 
without perturbation. After the transmission Bob tells Alice in 
which instances he detected a photon. In this case there is no 
need for reconciliation of basis sets between Alice and Bob 
to discriminate unambiguous measurements, as opposed to the 
BB84 protocol, which makes this protocol simpler and faster 
to execute. However, the B92 protocol is particularly vulner- 
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able to the “intercept-resend” eavesdropping attack. Eve can 
substitute the transmission channel for a perfectly transparent 
one and resend the photons to Bob, 1.e., she uses this "lossless” 
channel to hide the loss she introduces in the measurement. 
This eavesdropping attack is especially harmful, as Eve would 
not introduce an additional error to the Quantum Bit Error Rate 
(QBER)- a measure of how *secure” the transmission has been. 
However, the problem of simulating a noisy channel between 
Alice and Bob while extracting information of it is far from 
trivial [10]. Moreover, recently the security of the B92 protocol 
has been proven even in the presence of a lossy channel [11]. 


TI. REALISATION OF THE QKD FREE-SPACE SYSTEM 


The proposed short-distance QKD system is shown in 
Figures 1 and 3. The main goal is to securely transmit quantum 
keys between two locations in Madrid situated at a distance of 
3 km at high clock frequencies. These two locations are the 
Institute of Applied Physics, of the Spanish National Research 
Council (CSIC) and the Spanish telecommunications operator 
Telefonica. 


A. Realisation of the OKD transmitter: Alice 


Figure 1 shows the layout of the transmitter optics. To 
achieve high transmission rates Alice will use a fast GHz 
pre-programmed pulse pattern generator, able to generate 
pseudo-random sequences up to 2%! — 1 bits in length, in 
conjunction with A =— 850 nm vertical-cavity surface emitting 
lasers (VCSELS) controlled by high-speed drivers. The output 
of each laser is sent to a collimator by a single-mode at 
A “850 nm optical fibre. Two high extinction-ratio polarisers 
are used to generate the polarisation states required by the 
B92 protocol. These states are combined by a non-polarising 
beam splitter cube and the beam is then focused by a short 
focal length achromatic lens. Two high-quality mirrors lead the 
beam to a second achromatic lens which expands the beam to 
a diameter of = 40 mm. After the second lens the beam is 
ready to be transmitted to the receiver, Bob. The collimators, 
combining cube, mirrors and lenses are mounted on a 30 cm- 
side square platform. This platform is mounted on a high- 
precision gimbal system, which will be used for the alignment 
of emitter and receiver. 

The transmitter mounted on the gimbal system is shown 
in Figure 2. It consists of a structure which provides with 
the movements of Right Ascension (RA) and DEClination 
(DEC) with high precision. Once the initial or coarse pointing 
is performed, which will be discussed in section III, only 
two variables in spherical coordinates will be enough for 
the alignment of both stations. The motors employed have 
precision of microradians, have large loads capacities and are 
controlled by a programmable double-axis driver capable of 
implementing alignment and/or tracking algorithms. 

The motor in the base provides the RA movement while 
the lateral motor the DEC movement. In each lateral support 
a bearing holds a rod with an L-shaped holder where Alice is 
mounted on. 


4.25Gbps 


Ghz Pulse 
Generator 


Fig. 1. Diagram of the transmitter: Alice. V, and V2 are two VCSELs; 
A1 and Az are two fibre-optic attenuators; C1 and C2 are two fibre-coupled 
collimators; Pj and Pa are two high extinction-ratio polarisers; BS is a non- 
polarising beamsplitter; Ly and La are two achromatic doublet lenses; M1 
and Ma are two high-reflectivity mirrors. 


BM 


Fig. 2. AutoCAD design of the gimbal system for the transmitter. Two high 
precision DC motors - a lateral and a base motor represented in the figure by 
LM and BM - will provide the tip/tilt movements required for the alignment 
and tracking of Alice and Bob. 


B. Realisation of the OKD receiver: Bob 


Figure 3 shows the layout of the receiver. A Schmidt- 
Cassegrain telescope at Bob will efficiently focus the beam 
coming from Alice. After the telescope, a CCD camera will 
ease the alignment of emitter and receiver. Bobs optics has 
been designed to be coupled to the output of the telescope 
by using SM1 (25 mm) mounts, since they are light-weight 
and compact. Especial care must be paid to one of the most 
critical parts of the system, which is the filtering of the 
solar background radiation from the sun. For this purpose, 
a combination of spectral and spatial filters will be used. The 
spatial filtering will be carried out by optical fibre. A good 
compromise of the diameter of this fibre must be found, as 
small diameters improve the filtering of the solar radiation at 
the expense of higher signal losses. In addition, if the diameter 
1s too small the signal could be lost due to the beam wandering 
caused by the fluctuations of the index of refraction of the air. 
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Fig. 3. Diagram of the receiver: Bob. Two different wavelengths will be 
used: Asignal to transmit the quantum key, and Asyne to time stamp Alice 
and Bob. FM is a Flip Mirror; DM is a Dichroic Mirror; SF is a Spectral 
Filter; BS is a 50-50 non-polarising beamsplitter; Pj¡ and P2 are two high 
extinction-ratio polarisers; FC is a fibre patch cord; D¡ and Da are single 
photon detectors; D3 is an avalanche photodiode; and TIA is a Time Interval 
Analyser card. 


As previously mentioned, the states *1” and *0” are en- 
crypted by the two non-orthogonal polarising states used in 
the QKD protocol B92. These two states will be discrimi- 
nated by using a non-polarising beamsplitter and two high- 
extinction polarisers. Two silicon Single-Photon Avalanche 
Diodes (SPADSs) will be used to detect the photons from Alice. 
In addition, a high speed Time Interval Analyser (TIA) will 
detect the arrival time of each of the photons that reach the 
receiver and a software will process the received optical signal 
and establish the degree of security in the transmission. The 
electronic card acquired for this purpose measures the photons 
arrival time with high temporal precision and is able to perform 
3.5 millions of measurements per second with a timing jitter 
lower than 70 ps. The arrival times that this card provides will 
serve to reconstruct the signal sent by Alice and determine 
whether the transmission of the key has been secure or not, 
1.e. the QBER. The synchronisation timing of Alice and Bob 
will be performed by a different wavelength than that used for 
key transmission (Async And Asignar respectively in Figure 3). 
This will be discussed in detail in section IV. 


TIT. POINTING, ACQUISITION AND TRACKING 


Ideally a FSO link should be capable of reliable pointing, 
acquisition and tracking to offer optimal performance. The 
first, also known as coarse pointing, involves acquiring the 
approximate location of the receiver by using some prior 
information and aiming the transmitter in the proper direction. 
Spatial acquisition refers to the operation the receiver does to 
determine the direction of arrival of the transmitter's beam. 
Once coarse pointing and spatial acquisition are performed, 
emitter and receiver have determined their Line of Sight 
(LOS). Spatial tracking refers to the operation of maintaining 
this LOS with minimum error throughout the transmission. 
Coarse pointing can be performed by several means. If the 
distances involved are only a few kilometres, GPS or optical 
imaging systems can be used. The first uses the stamps from 
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Fig. 4. Tracking of the QKD system. Two computers (PC) will control 
both the transmitter and receiver's gimbals providing tip/tilt movements, A9 
and Ad, required for the alignment and tracking of both stations. Two Focal 
Plane Arrays (FPA) in the transmitter and receiver will detect any deviation 
of the position of both beacon lasers, BL1 and BLa2, and order the motors 
to compensate for them. Mi and Ma are two mirrors. 


several satellites to compute the location of the target. How- 
ever, this suffers from lack of satellite accessibility at certain 
times or locations. Optical imaging consists of visualising the 
target using lenses or CCD cameras. In this case, the advantage 
comes from the full accessibility of the cameras at any time. 

Spatial tracking requires from both the emitter and receiver 
to make adjustments to maintain the alignment of the optical 
beam. One method involves the use of beacon lasers in combi- 
nation with Focal Plane Arrays (FPA) [12][13] (see Figure 4). 
A Focal Plane Array is an image sensing device made of 
a rectangular array of light-sensitive pixels that reproduce a 
real image according to the intensity of light received by each 
pixel. When Alice and Bob are aligned an image of the beams 
1s recorded by the FPA and the distance between the spots is 
computed. At this position both beams are parallel. Therefore 
any change in the relative position of the spots means the 
beams are no longer parallel and the computer-driven high- 
precision gimbal motors receive a signal to counteract this 
misalignment. For this method to work effectively Alice needs 
to send her data signal parallel to her beacon laser. Both beams 
can be generated by different lasers or else Alice can use her 
data laser as a beacon laser but this means that part of her 
data signal will be sacrificed for the alignment of the system. 

If no tracking is performed large beam diameters must 
be used for the transmission at long distances in order to 
minimise the effects of atmospheric turbulence and mechanical 
vibrations of the equipment on the beam alignment. However 
larger beam diameters need big telescopes to efficiently detect 
them and usually a considerable part of the signal is lost. 
In QKD systems, optical amplifiers or quantum repeaters are 
still beyond current technology and therefore losses must be 
avoided by all means. Hence tracking becomes a necessity in 
this kind of systems. 

In summary, along with a properly collimated beam, a high 
precision mounting platform for Alice is required in order to 
effectively perform the pointing of the system. An actively 
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controlled mechanism will be used to compensate for any 
misalignment of the optical beam to maintain the line of sight. 
In our system, Alice and Bob will be both mounted on gimbals 
and the coarse pointing will be performed by two CCD 
cameras. Fine pointing and active tracking will be performed 
by aligning both gimbals with the help of two beacon lasers, 
one from Alice to Bob and the other from Bob to Alice. The 
wavelength of the beacon lasers will be different from that 
used by the data laser, making both channels independent. 
Both wavelengths will be separated by the help of dichroic 
and interference filters at both ends. Once the beacon beams 
are aligned, the tracking mechanism will detect any deviation 
and consequently send a signal to each gimbal driver to realign 
the beams. 


IV. SYNCHRONISATION AND QBER ANALYSIS 


The method we have chosen to synchronise Alice and Bob 
utilises a periodic bright pulse of a different wavelength from 
that used for the key, as precursor to open a time gate for the 
subsequent signal photons. This timing pulse will be sent at 
a different wavelength in parallel with the quantum channel 
at 850 nm. Both wavelengths will be separated in Bob by 
a dichroic mirror and interference filters. The frequency of 
the synchronisation or timing pulse will be a sub-multiple of 
the clock frequency. At the receiver, the arrival time of the 
timing pulse is utilised as an arm signal that activates a timing 
gate in which QKD data is expected. We believe this type 
of synchronisation in conjunction with a GHz-clocked source 
will result in secure key transmission rates considerably higher 
than those currently achieved. 

Moreover, a software algorithm that determines the QBER 
and corrects for additional errors is being programmed. As 
stated by Shannon's theorem [14] a minimum of bits must be 
sent via the classical channel to correct the errors. Recently, 
Low Density Parity-Check Codes (LDPC) codes have been 
proposed along with a simple iterative decoding algorithm 
[15]. These codes have been demonstrated to perform very 
close to the Shannon limit. The advantage of LDPC compared 
to standard Cascade error correction algorithms, is that LDPC 
has the potential of a faster implementation as it requires only 
one round. 


V. CONCLUSIONS 


There is a growing demand for more bandwidth in certain 
regions of metropolitan networks due to lack or poor connec- 
tions. High-speed links using free-space optics is an attractive 
solution and QKD free-space links can offer both speed and 
security to this problem. 

In this line, a high-bit-rate free-space QKD system for 
urban-span secure communication links has been designed. To 
achieve high speed transmission a high-clock-frequency pulse 
generator combined with high-data transmission laser diodes 
and drivers at Alice has been utilised. Moreover, an optical 
synchronisation at a different wavelength will permit faster 
key generation than those currently achieved. In addition, the 


proposed tracking system controlled by high-precision motors 
will allow continuous operation of the presented QKD system. 
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Resumen—Las Infraestructuras Críticas (ICs) son monitor- 
izadas por sistemas altamente complejos, conocidos como sis- 
temas SCADA (Sistemas de Control y Adquisición de Datos), 
cuyo principal soporte se encuentra en las subestaciones, las 
cuales miden de primera instancia el estado real de tales ICs. 
Para mejorar este control, la industria está actualmente deman- 
dando la integración en el modelo tradicional de dos avances 
tecnológicos: Internet y las redes de sensores inalámbricas. Sin 
embargo, su incorporación requiere analizar los requisitos de 
seguridad que surgen en dicho contexto, así como diversos aspec- 
tos correlacionados (ej. mantenimiento, rendimiento, seguridad 
y optimización) y, en base a estos, la estrategia de integración 
más adecuada para satisfacer dichos requisitos. Este artículo 
proporciona dicho análisis en profundidad con el fin de ofrecer 
un modelo de integración seguro adecuado para entornos críticos. 


Index Terms—Sistemas Críticos de Control, Sistemas SCADA, 
Redes Mesh Inalámbrica de Sensores, el Internet, Internet of 
Things. 


I. INTRODUCCIÓN 


La introducción de nuevas tecnologías y diferentes tipos 
de sistemas de comunicación en las redes de control indus- 
triales está impulsando nuevos e importantes avances en los 
procesos de automatización y control. Un caso particular son 
los SCADA que emplean nuevas tecnologías para monitorizar 
en tiempo real muchas de las infraestructuras críticas (ICs) 
desplegadas en nuestra sociedad, tales como los sistemas 
de energía, de transporte o distribución de agua/aceite. Es- 
pecíficamente, en estos momentos dos de las tecnologías más 
demandadas son las redes inalámbricas e Internet. El primero, 
dado que proporciona los mismos servicios de control que una 
infraestructura cableada, pero con un bajo coste de instalación 
y mantenimiento. El segundo, al ofrecer conectividad global 
independientemente de la posición física de los dispositivos, 
tales como nodos sensores configurados en las subestaciones 
para controlar las infraestructuras críticas. 

La imagen 1 muestra un sistema SCADA actual [1], donde 
los operadores autenticados y autorizados gestionan los flujos 
de datos transmitidos por las subestaciones. Una subestación 
remota se compone de dispositivos de campo, conocidos como 
Unidades Terminales Remotas (RTUs), capaces de recolectar, 
gestionar y transmitir los flujos de datos recibidos de sus 
sensores. Por otra parte, la imagen muestra también nuevas 
tecnologías adoptadas recientemente por las subestaciones, 
tales como redes de sensores inalámbricas (Wireless Sensor 
Networks o WSNs). Este tipo de red es una de las tecnologías 
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SCADA 


Cola E e DNP3, IEC-104 


Figura 1. A current SCADA network architecture 


más demandadas por los ingenieros industriales, dado que 
ofrece servicios de control similares a una RTU, pero con 
un bajo coste de instalación. Sin embargo, tales servicios 
no están siendo todavía explotados apropiadamente, dado 
que los estándares de comunicación únicamente contemplan 
conectividad local. Debido a esto, tanto la industria como la 
comunidad científica están tratando de maximizar esfuerzos 
para ofrecer tales servicios a través de Internet. Como resulta- 
do, un nuevo paradigma comienza a emerger en el contexto de 
las infraestructuras críticas, la Internet de los Objetos (IoT). 

La loT está formada de diversas infraestructuras het- 
erogéneas de comunicación interconectadas, donde Internet, 
los servicios y objetos físicos juegan un importante rol en 
los procesos de control y automatización. El interés por abrir 
los procesos de comunicación en ICs a la red de redes y 
la inminente expansión de los nuevos paradigmas de comu- 
nicación ha motivado el desarrollo de diversos trabajos de 
investigación. Así, Li et. al propusieron en [2] un sistema 
basado en web para RTUs inteligentes con capacidad para 


interpretar HTTP, Jain et. al presentó en [3] un sistema experto 
basado en web para diagnóstico y control de sistemas de 
energía e incluso algunas compañías comerciales tales como 
Yokogawa [4] o WebSCADA [5] están ya proporcionando 
soluciones de control utilizando Internet. 

En particular, las WSNs, como parte de los objetos de la 
loT, pueden crear una capa virtual, autónoma e inteligente 
sobre el entorno físico de subestaciones remotas, proporcio- 
nando información sobre el estado del mundo real que puede 
ser accedido en cualquier momento y lugar. De hecho, los 
gobiernos de alrededor del mundo han previsto el potencial 
de las WSNSs en infraestructuras críticas y las han incluido 
en sus planes nacionales para investigación y desarrollo, tal 
como el gobierno australiano, a través de su Research Network 
for a Secure Australia (RNSA) [6], o el gobierno de los 
Estados Unidos en sus planes de protección para ICs [7],[8]. 
La comunidad científica e industrial está realizando diversas 
investigaciones para la adopción de las WSN en CIP. Por 
ejemplo, Bai et al. [9] ha implementado las WSN en un sistema 
SCADA para la monitorización de la energía generada por una 
planta de energía eólica. Carlsen et. al. introdujeron en [10] 
una WSN capaz de predecir la pérdida de aceite/gas en una 
planta submarina en el Mar del Norte. 

La interacción de las WSN en las ICs a través de Internet se 
puede lograr empleando múltiples estrategias de integración: 
desde nodos sensores que implementen la pila TCPAP y se 
conviertan en miembros completos de la loT, a redes capilares 
que mantengan su independencia, pero empleen los servidores 
de Internet como interfaz hacia las entidades externas. Sin 
embargo, este camino presenta diferentes problemas que no 
han sido aún estudiados en profundidad en la literatura, tales 
como qué estrategia de integración debería emplearse en la 
integración de las WSN industriales en loT, qué problemática 
de seguridad surgirá debido a esta evolución de la arquitectura 
de red y cómo asegurar que los requisitos de seguridad de 
los sistemas críticos se satisfacen en este paradigma de red. 
El objetivo de este artículo es proporcionar una base para la 
respuesta a estas cuestiones, analizando los requisitos de se- 
guridad e infrastructurales de las WSN industriales conectadas 
a Internet y discutiendo la adecuación de las estrategias de 
integración que harán realidad la visión de gestión ubicua en 
el área de las redes industriales. 

El artículo se organiza de la siguiente manera. La sección 
II describe los requisitos que deben ser considerados para 
alcanzar una integración segura. La sección III presenta las 
estrategias de integración susceptibles de ser adoptadas. La 
sección IV proporciona una análisis de la integración entre 
WSN e Internet en el contexto de las redes de control dados los 
requisitos mencionados previamente. La sección V concluye 
el artículo y muestra las líneas de trabajo futuro. 


II. REQUISITOS DE WSN INDUSTRIALES 


Con objeto de proporcionar sus servicios, los sensores 
industriales inalámbricos podría beneficiarse sustancialmente 
de su integración en la loT. La colaboración y agregación de 
datos críticos entre sensores geográficamente dispersos se vería 
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mejorada, proporcionando información más fiable y precisa. 
Más allá, tanto los operadores de sistemas como los usuarios 
finales (con privilegios restringidos) podrían beneficiarse del 
acceso en tiempo real desde cualquier lugar a la infraestructura 
reduciendo costes. Sin embargo, a pesar de que es posible uti- 
lizar diferentes estrategias para conectar las WSNSs a Internet, 
es necesario conocer cuál es más adecuada para los requisitos 
de cada escenario. El objetivo de esta sección es introducir 
tanto los requisitos específicos de las WSN industriales antes 
de presentar las diferentes estrategias de integración. 


Il-A. Requisitos de Control y Automatización 


Para estudiar la seguridad de las WSN industriales en 
el contexto de Internet, es esencial considerar no sólo los 
requisitos de seguridad, sino también los requisitos que tales 
redes de control deben satisfacer, tales como mantenimiento, 
rendimiento del sistema y fiabilidad de los recursos y servicios. 
El motivo es simple: algunos de estos requisitos tienen una 
influencia directa sobre los requisitos de seguridad y viceversa, 
tales como la sobrecarga en memoria o tiempo de respuesta 
del nodo debido a los mecanismos de seguridad empleados. 
Debido a ello, esta subsección introduce los requisitos básicos 
(incluyendo los de seguridad) que deben considerar tanto 
sistemas de control como industriales . 

Il-Al. Mantenimiento: Es necesario realizar el manten- 
imiento del software y hardware de las subestaciones. Para 
prevenir la aparición de errores, cada dispositivo debe ser 
debidamente configurado, y deben realizarse tests periódicos 
de su estado. Además, los componentes software deben estar 
actualizados con las revisiones críticas, así como añadirse 
nuevo hardware a la subestación cuando éste es necesario. 
Por tanto, las propiedades asociadas al mantenimiento son: 


= Direccionamiento. Es necesario especificar un tipo de 
identificación única para cada elemento presente en la 
subestación de forma que sea posible acceder al flujo 
de datos que éste produce. Esta propiedad se relaciona 
con cómo se accede a los diferentes identificadores de 
los dispositivos y quién se encarga de almacenar dichas 
identidades. 

= Acceso Interno. Los servicios ofrecidos por los dis- 
positivos que se encuentran en la subestación deben 
se accecidos de forma local por los operadores de las 
subestaciones, ya sea por motivos de testeo o de redun- 
dancia. Esta propiedad se relaciona con la complejidad 
actual de acceder a los dispositivos de la subestación de 
forma local. 

= Mantenibilidad. Como con cualquier dispositivo, el soft- 
ware de las RTUs deberá ser actualizado debido a op- 
timizaciones o parches de seguridad entre otros. Esta 
propiedad se refiere al número de dispositivos que deben 
cambiar con objeto de actualizar la funcionalidad de la 
subestación. 

= Extensibilidad. El número de RTUs que puede encon- 
trarse en una subestación concreta cambia a lo largo del 
tiempo de vida de la infraestructura. Esta propiedad se 


relaciona con los cambios totales que deben realizarse en 
la subestación para incluir nuevo hardware. 


II-A2. Fiabilidad: La funcionalidad proporcionada por la 
subestación debe ser suficientemente fiable para ofrecer sus 
servicios con unos niveles de calidad concretos. Los flujos de 
datos provistos por las RTUs deben estar disponibles en todo 
momento, y cualquier consulta relativa al contenido actual de 
dichos flujos de datos debe llegar al sistema central tan rápido 
como sea posible. Consecuentemente, las propiedad asociadas 
a la fiabilidad son: 


= Disponibilidad!. Los datos producidos por las RTUs 
deben estar disponibles en todo momento con objeto 
de reaccionar a situaciones problemáticas y asegurar la 
integridad del sistema completo. Como propiedad, se dan 
dos dimensiones de la misma: la fiabilidad (empleando 
la redundancia del sistema para evitar los puntos únicos 
de fallo) y la seguridad (existencia de ataques de dene- 
gación de servicio y el empleo de mecanismos de sanado 
para proporcionar los servicios incluso en el caso de 
ataques/fallos en el sistema). 

= Rendimiento. La información debe ser recuperada de 
las RTUs a velocidad suficiente. Como propiedad, el 
rendimiento se relaciona con las capacidades hardware de 
los dispositivos de la subestación, además de la velocidad 
actual de la infraestructura de la red de la subestación, 
y el número de saltos entre la RTU y el repositorio de 
datos. 


IF-A3. Sobrecarga: Es necesario lograr un balance entre 
el número de recursos disponibles al dispositivo y su coste 
global. Los dispositivos no deberían recibir una sobrecarga de 
trabajo, pero tampoco deberían de dedicarse recursos innece- 
sarios. Más allá, aquellos recursos deberían optimizarase para 
funcionar en el entorno de la subestación. Consecuentemente, 
las propiedades asociadas con la sobrecarga son: 


= Recursos del Dispositivo. Con objeto de implementar 
los diferentes protocolos que proporcionan la funcional- 
idad central de las subestaciones, tales como DNP3 o 
WirelessHART, los dispositivos deben usar parte de sus 
recursos HW y SW. Esta propiedad referencia la cantidad 
de recursos que se necesitan dentro de un nodo para 
implementar dichos protocolos. 

= Optimización. Hay algunos protocolos específicos que se 
han optimizado para proporcionar la mejor funcionalidad 
posible en un entorno particular. Esta propiedad se rela- 
ciona con la existencia de protocolos específicos de red 
(tales como WirelessHART), que son conscientes de las 
características específicas del entorno de red y utilizarlos 
para proporcionar mejores servicios (por ej. redundancia 
de red y robustez del enlace). 


II-A4. Seguridad: La seguridad de los diferentes proce- 
sos de una subestación es materia de máxima importancia. 


lLa disponibilidad puede considerarse como un requisito de seguridad, pero 
ha sido clasificada como un requisito de fiabilidad debido a su relación cercana 
a la dimensión funcional de la subestación. 
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Cualquier problema que afecte a la integridad de los elemen- 
tos de una subestación tendrá potencialmente una influencia 
sobre el mundo real, afectando no sólo a las infraestructuras 
físicas, sino a los seres humanos. Por lo tanto, sólo usuarios 
autorizados deben de disponer de privilegios para modificar 
el estado de los elementos de las subestaciones, y únicamente 
los usuarios fiables deben poder acceder a los flujos de datos 
producidos por las subestaciones. De manera adicional, deben 
existir mecanismos que almacenen las interaciones entre los 
diferentes elementos, para facilitar no sólo el análisis del 
comportamiento del sistema, sino también la detección de 
posibles brechas de seguridad. Por lo tanto, las propiedades 
asociadas a la seguridad son: 


= Canal Seguro. Allá donde dos dispositivos que pertenez- 
can al mismo sistema SCADA (por ej. una máquina 
del sistema central y una RTU de una subestación)se 
comuniquen, es importante establecer un canal seguro 
que soporte servicios de integridad y confidencialidad 
extremo-a-extremo. La integridad del flujo de datos evi- 
tará la introducción de información falsa en el sistema. 
Además, la confidencialidad del flujo de información 
evitará el acceso de adversarios a información sensible. 
Como propiedad, referencia al tipo de máquinas y mecan- 
ismos que se ven envueltas en la creación de un canal de 
comunicación que soporte confidencialidad e integridad. 

= Autenticación. En lo que se refiere a la autenticación de 
usuario, los dispositivos deben asegurarse de la identidad 
de un usuario que solicite una operación concreta. Como 
propiedad, la autenticación se refiere a la localización 
y la naturaleza de los mecanismos y elementos que 
pueden emplearse para proporcionar la identidad de un 
ser humano. 

= Autorización. Una vez que cualquier usuario de la red 
(sea un humano o una máquina) proporciona su identi- 
dad, puede ser necesario comprobar si tal usuario tiene 
los derechos para acceder a la información. No sólo se 
debe controlar el acceso a la información, sino también 
la granularidad de la información. Es también necesario 
monitorizar las operaciones de control (por ej. los dis- 
positivos deben ser sólo reprogramados por los usuarios 
autorizados). Como propiedad, la autorización referencia 
a los tipos de mecanismos, credenciales y herramientas 
que pueden emplearse para comprobar si una cierta 
entidad está autorizada a realizar una operación. 

= Registro y detección. Es necesario mantener un registro 
de las interaciones de los heterogéneos usuarios que 
acceden a los servicios de una subestación. Tal registro 
permitirá recrear los incidentes de seguridad y las situa- 
ciones anormales. Además, podemos detectar ataques 
específicos en tiempo real. Como propiedad, el registro 
y la detección referencian a la estructura de los sistemas 
de registro y los mecanismos que pueden emplearse para 
analizarlos. 
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Figura 2. Estrategias de integración 


III. ESTRATEGIAS DE INTEGRACIÓN 


Actualmente existen dos formas de integrar las WSNSs 
industriales en Internet, las cuales van a depender de la (1) 
pila de protocolo o de la (11) topología de la red. Para 
la primera clasificación, es necesario comprender las simil- 
itudes existentes entre ambas tecnologías, obteniéndose tres 
posibles soluciones/modelos (ver Figura 2): Front-end (la 
WSN es independiente del Internet), Gateway (intercambio 
de información a través de nodos especiales de Internet), 
y TCPAP (los nodos implementan la pila TCP/IP). Para 
entrar en más detalle, comentaremos cada uno de estos casos. 
Por ejemplo, para una solución Front-end, tanto el centro 
SCADA como las WSNs en las subestaciones remotas no 
establecen comunicaciones directas, permitiendo a las WSNs 
tener implementada su propias pilas de protocolos (ZigBee, 
WirelessHART, ISA100.11.a). En este caso, las interacciones 
entre ambos extremos deben residir en una interfaz capaz de 
traducir los respectivos protocolos (ej. una RTU), facilitando 
la consulta y el control de las subestaciones. 

En una solución Gateway, también se considera la existencia 
de un nodo especial capaz de actuar como un gateway a 
nivel de aplicación (ej. una RTU), con el fin de traducir los 
protocolos de las capas inferiores provenientes de ambas redes 
(ej. TCP/IP y Modbus), además de enrutar la información de 
un punto a otro (como hace el front-end), sin necesidad de 
conexión directa con el Internet y sin requerir que la propia 
pila de WSN cambie. Finalmente, en la solución TCP/IP, 
los nodos sensores ya forman parte del Internet, al tener 
implementado dentro de su lógica el estándar TCP/IP o un 
conjunto de protocolos compatibles (como 6LowPAN [11] en 
redes 802.15.4 [12]). Esta solución es precisamente la que 
podría integrar las WSNs industriales en el contexto de loT 
(Internet of Things). 

Por el contrario, en la segunda clasificación, el nivel de 
integración va a depender de la localización física de aquellos 
nodos responsables de proveer acceso a Internet, como pueden 
ser: (i) estaciones bases localizadas en la raíz de un diseño 
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de WSN híbrida (solución Híbrida) o (ii) nodos backbone 
dedicados a proveer puntos de accesos a Internet en un salto 
(solución Punto de Acceso). Las WSNs del primer caso, se 
caracterizan por ofrecer redundancia cuya información debe 
pasar a través de ellas. Por el contrario, las redes diseñadas 
bajo una solución de Punto de Acceso presentan una topología 
de red en forma de árbol cuyas hojas corresponden a nodos 
sensores y el resto son considerados puntos de accesos a 
Internet. Ambas clasificaciones pueden funcionar conjunta- 
mente, permitiendo que nodos backbones o estaciones bases, 
puedan funcionar como front-ends/gateways, favoreciendo los 
accesos directos entre los nodos y el centro SCADA. Sin 
embargo, combinar un modelo de red TCP/IP con soluciones 
Híbridas/Punto de Acceso puede no tener mucho sentido, al 
existir en los nodos sensores una vía de acceso directa hacia 
el Internet. 


IV. ANÁLISIS DE MECANISMOS DE INTEGRACIÓN 


Una vez conocidas las diferentes estrategias de integración, 
es necesario discutir las (des)/ventajas de cada una de ellas en 
un contexto industrial. Para ello, es necesario considerar las 
propiedades de la Sección II 

1) Mantenimiento: En términos de direccionamiento, tanto 
las soluciones Front-end como el Gateway requieren de una 
tarea de de traducción de identidades a una dirección de un 
nodo de la red, por lo que el nodo responsable (es decir, la 
RTU) deberá mantener una tabla de direcciones. En cambio, 
si la solución es TCP/IP, dicha tabla de direcciones debe ser 
localizada en el centro SCADA para transmitir directamente 
hacia el Internet. Luego, existen dos tipos de redes: descen- 
tralizados o centralizados. Obviamente, la gestión en una 
red centralizada, como una red Híbrida o de Punto de Acceso, 
será mucho más costosa que la descentralizada al requerirse 
una replicación de tablas de direcciones en las estaciones bases 
o backbones o una interfaz intermediaria que permita realizar 
las traducciones. 

Por otro lado, e independientemente de la solución, los 
operadores tienen que llevar a cabo tareas de mantenimiento 
mediante conexiones TCP/IP (acceso interno) a la propia 
subestación, con el fin de acceder a los servicios de recu- 
peración de datos. También cabe la posibilidad de que los 
operadores en campo puedan acceder directamente a servicios 
locales del propio protocolo de WSN (p. ej. ISA100.11a), tal 
como ocurre en soluciones Front-end y Gateway. En cambio, 
en modelos TCP/IP se requiere conocer de antemano la direc- 
ción de red del sensor. Por último, esta propiedad puede ser 
un poco más compleja en soluciones de Punto de Acceso, ya 
que se necesita que los operadores estén físicamente cercanos 
a los nodos que deseen acceder. 

El mantenimiento SW de los nodos sensores va a depender 
del número de dispositivos a ser actualizados (nuevos ser- 
vicios SCADA). En soluciones Front-end, el proceso afecta 
únicamente a un dispositivo de la red (la RTU), el cual 
requiera parar los procesos de control y la disponibilidad de 
la WSN momentáneamente con el fin de llevar a cabo las 
tareas de mantenimiento. En cambio, las soluciones Gateway 


y TCP/IP ofrecen actualizaciones graduales en todos los nodos 
sensores implicados, asegurando continuidad y funcionalidad. 
Igualmente, la solución Híbrida es también capaz de ofrecer 
tales actualizaciones graduales al proveer redundancia de ele- 
mentos, mientras que la solución de Punto de Acceso puede no 
ofrecerla, ya que los nodos están conectados de alguna forma 
a un determinado nodo backbone. En lo que respecta a la 
extensibilidad, tanto el Front-end como el Gateway requieren 
incluir una nueva entrada en la tabla de traducciones para hacer 
funcionar los servicios específicos de las WSNSs, mientras que 
en soluciones TCP/IP son precisamente los nodos sensores los 
encargados de añadir nuevas entradas (de manera individual). 
Igualmente, esta propiedad también podría afectar a tanto 
soluciones Híbridas como de Punto de Acceso, excepto en el 
caso particular que dichas tablas sean gestionadas de manera 
distribuida. 

3) Sobrecarga: Recursos de los dispositivos están rela- 
cionados con todas aquellas soluciones (Híbrida, Punto de 
Acceso y TCP/IP) que requieran ciertas capacidades SW y 
HW en los nodos para implementar protocolos de aplicación 
y servicios de seguridad. Sin embargo, aunque los nodos sen- 
sores industriales aparentemente provean ciertas capacidades 
computacionales y recursos, estos siguen presentando ciertas 
complejidades (como los nodos convencionales). Con lo que 
respecta a la optimización, todos aquellos modelos (como el 
Front-end, Gateway, Híbrida y Punto de Acceso) que hacen 
uso de protocolos específicos de WSN (p. ej. WirelessHART 
o ISA100.11a), pueden beneficiarse de los servicios ofrecidos 
por ellos (p. ej. sincronización mediante una determinada TD- 
MA, mecanismos de control de interferencias y coexistencia 
con otras tecnologías, mecanismos de diagnósticos, gestión 
de prioridades y gestión de rutas redundantes). La mayoría 
de estos servicios propios no están contemplados por la pila 
TCP/1P. 

3) Seguridad: Para conseguir un canal seguro se requiere 
mecanismos que aseguren confidencialidad e integridad en 
todas las comunicaciones, es decir, desde el centro SCADA 
hasta las WSNSs. En el modelo TCP/IP es posible proveer tales 
servicios, ya que cada nodo final tiene implementado de alguna 
forma la pila TCP/IP. Incluso, aunque no sea posible hacer uso 
de las ventajas de IPSec debido a la naturaleza restrictiva de 
los sensores [13], es posible hacer uso de SSL/TLS imple- 
mentados en la capa de transporte o WS-ConversacionSegura 
en la capa de aplicación para aquellas redes que hacen uso 
de servicios Web. Estos mismos mecanismos de aplicación 
podrían ser también viables en un modelo Gateway, ya que 
sus capacidades se centran en reenviar la información. Por el 
contrario, una solución Front-end necesita proteger el canal 
de dos formas: (1) con mecanismos de seguridad TCP/IP y 
(11) con mecanismos de protección específicos de las WSNs 
(ej. claves simétricas de WirelessHART). Finalmente, es im- 
portante comentar que tanto el modelo Front-end como el 
Gateway permite implementar una red privada virtual (VPN) 
entre el centro SCADA y el front-end/gateway, asegurando la 
confidencialidad y la integridad de los mensajes de control. 

Uno de los principales desafíos en lo que respecta a la 
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autentificación es determinar la localización de los servicios de 
autentificación de usuario y el almacenamiento de las creden- 
ciales de seguridad, como usuario/contraseña. El modelo más 
simple es el Front-end, ya que es justo el nodo quién tiene 
que almacenarlos y gestionarlos. En cambio, estos servicios 
de seguridad son distribuidos en disversos puntos de la red 
en las demás soluciones. Una posible solución sería aplicar 
protocolos y mecanismos de seguridad de manera centralizada 
con el fin de gestionar en un mismo punto toda la información 
relativa a la autentificación (ej. Kerberos [14]). No obstante, 
estas soluciones podrían añadir ciertas complejidades a los 
nodos sensores al requerir el uso de servicios adicionales para 
validar las credenciales. Para evitar este hecho, una posible 
solución sería replicar las bases de datos de credenciales, con 
el problema añadido de que se podría dificultar los procesos de 
mantenimiento del sistema completo. Con respecto al modelo 
Gateway, una medida de seguridad sería configurar canales 
dedicados y seguros entre el usuario y el gateway justo después 
de realizarse un proceso de autentificación. 

La propiedad de autorización es similar a la de autentifi- 
cación, con la excepción de que es necesario conocer dónde 
almacenar los servicios asociados a la autorización y los 
permisos de usuarios. Por consiguiente, las mismas soluciones 
para la autentificación son efectivas para la autorización. Sin 
embargo, el uso de bases de datos distribuidas podría incluir 
una importante complejidad al sistema, ya que los permisos 
de usuarios tienden a cambiar con mayor frecuencia. 

En cuanto al registro, es necesario almacenar todas las 
interacciones entre el sistema central y los nodos sensores. 
Una medida óptima sería diseñar un modelo de red totalmente 
centralizado, como podría ser un modelo Front-end y un 
Gateway, e incluso, si existe mecanismos de seguridad im- 
plementados punto a punto, la solución Gateway podría filtrar 
cierta información manteniendo dicha naturaleza centralizada. 
En cambio, un modelo descentralizado, como el TCP/IP, 
podría suponer ciertas complejidades de almacenamiento en 
los sensores, ya que serían ellos los que deberían registrar 
todas las interacciones ocurridas en el sistema. Igualmente, la 
detección debería implementarse en soluciones centralizadas, 
ya que supondría incrementar la inteligencia del nodo con 
nuevas reglas de detección, reduciendo sus capacidades lógicas 
para procesar otros tipos de tareas. Este mecanismo se hace 
prácticamente esencial para ayudar a detectar posibles mal- 
funcionamientos y ataques internos, por lo que se recomienda 
seguir investigando en la elaboración de reglas y patrones 
sencillos (no complejos) para WSNs. 


IV-A. Discusiones 


Considerando los análisis realizados anteriormente, nuestro 
principal objetivo ahora es determinar la validez de tales 
estrategias en un contexto industrial. Por ejemplo, en una solu- 
ción TCP/IP, las WSNs localizadas en subestaciones remotas 
son consideradas partes del Internet, pero sin embargo, este 
hecho podría no ser tan ventajoso. En términos de seguridad 
es necesario proteger la WSN desde cualquier tipo de intruso, 
ya que un incremento en el tráfico de red podría suponer una 


reducción de funcionalidad en los nodos sensores debido a 
sus limitadas capacidades. La autenticación y la autorización 
pueden ser resueltas, en un principio, mediante soluciones 
centralizadas como kerberos. Por otro lado, los nodos que 
tienen implementado la pila TCPAP y no tienen suficientes re- 
cursos para implementar protocolos específicos WSNs (Wire- 
lessHART o ISA100.11a), no llegan a beneficiarse de los servi- 
cios de optimización ofrecidos por éstos, e incluso, no pueden 
implementar mecanismos de almacenamiento y reenvío para 
ganar redundancia de datos, así como la gestión de datos en 
caché. No obstante, este modelo podría ofrecer ciertas ventajas 
en lo que respecta el mantenimiento SW gradual y resistencia a 
fallos, sin aislar la funcionalidad total del sistema/subsistema. 

Por otro lado, los nodos sensores de un modelo Front-end 
pueden hacer uso de los estándares existentes para imple- 
mentar mecanismos de seguridad cuya funcionalidad reside 
en un único punto. Sin embargo, este hecho podría suponer 
riesgos de aislamiento al tratarse de un punto vulnerable a 
ataques de denegación de servicios. Una posible solución sería 
implementar un modelo de red Híbrida o Punto de Acceso, 
aunque ésto podría suponer nuevos problemas asociados a la 
replicación de recursos. Otra ventaja de usar Front-end es el 
uso de servicios óptimos ofrecidos por los estándares específi- 
cos de WSNSs y la posibilidad de configurar mecanismos de 
seguridad que ayuden a mejorar la resistencia (p. ej. rutas 
redundantes). Por último, aunque el mantenimiento SW de la 
red es simple (actualización en un nodo), existe el riesgo de 
aislar la funcionalidad de la red durante un periodo de tiempo 
crucial. Para ello, se recomienda replicar nodos, tal como hace 
los modelos Híbridos y Punto de Acceso. 

En lo que respecta al modelo Gateway, éste puede ser con- 
siderado una mezcla entre las dos primeros. En particular, ésta 
ofrece algunas implementaciones dadas por el Front-end, como 
puede ser el uso de servicios óptimos específicos de WSN e 
implementaciones de almacenamiento y reenvío, permitiendo 
a su vez realizar consultas directas al centro SCADA. No 
obstante, la funcionalidad del Gateway podría añadir compleji- 
dades a los nodos, además de considerar detalles de seguridad 
como la autentificación y la autorización. Además, el gateway 
debería filtrar las entradas para analizar las consultas y evitar 
ataques específicos de aplicación y considerar aspectos como 
la complejidad añadida en los procesos de mantenimiento SW. 
Por último, esta solución puede ser combinada con modelos 
de red Híbridas y de Punto de Acceso para configurar redun- 
dancíia, aunque es también esencial considerar los problemas 
relativos a estos modelos, como pueden ser la distribución de 
tablas y recursos. 

Por consiguiente, parece interesante usar una solución 
puramente TCP/IP en subestaciones remotas, sin embargo, 
esta solución podría no ser suficiente para una integración 
total de WSNs en Internet bajo un contexto industrial. Además, 
como los sistemas de control simplemente acceden a flujos 
de datos y realizan tareas de control bajo comandos, otras 
soluciones, como el Front-end combinadas con modelos que 
provean redundancia, podrían ser a priori suficientes para 
las necesidades actuales de la industria. No obstante, es 
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importante comentar que una integración segura y completa de 
una WSN en el Internet podría brindar al sistema con nuevos 
e interesantes mecanismos de control, algunos de los cuales 
harían uso de servicios Web. 


V. CONCLUSION 


Desde que los nodos sensores son parte del loT e Internet de 
la Energía, nuevos desafíos de investigación están comenzado 
a emerger, los cuales están resumidos en este artículo bajo un 
análisis de integración (segura) de nodos sensores en Internet 
bajo un contexto industrial. Como conclusión de este análisis 
vemos que actualmente no es necesario integrar totalmente 
las redes de sensores industriales dentro de Internet y que 
una simple red basada en redundancia podría ser, por ahora, 
suficiente para ofrecer la funcionalidad deseada. Sin embargo, 
queda pendiente para un futuro investigar cómo explotar el 
potencial y funcionalidad ofrecido por Internet junto al uso 
de nodos sensores industriales para así garantizar nuevas e 
interesantes aplicaciones de control. 
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Abstract—On-line Social Networks (OSN) have become the 
most popular Internet service today. OSN are being embraced 
by companies and organisations to help connecting people, 
assist dealing with cooperative tasks, and develop marketing 
and public relations campaigns. Despite all their benefits and 
advantages, as happens with every new technology, they are prone 
to several security issues. In addition to privacy concerns, there 
are many other dangerous vulnerabilities that affect security. 
In this paper, we present our Threat Modelling in OSN, which 
focuses on identifying attacks against users of OSN and possible 
countermeasures to mitigate the risks. 


IT. INTRODUCTION 


On-line Social Networks (OSN) have become the most 
visited sites surpassing information gatherers like Google, 
MSN, or Yahoo!, consuming most of the time that users spend 
connected to the Internet, both via desktop and mobile devices. 

Although there is no accepted and universal definition for 
OSN, this paper will use the working definition provided by 
INTECO and the Agencia Española de Protección de Datos 
[1]: 

“Services that let their users to create a public profile where 
they can introduce personal data and information. The users 
have different tools to interact with each other.' 

Many enterprises are embracing OSN and integrating them 
within their strategic plans: viral marketing campaigns; collab- 
orative working environments within the enterprise to allow a 
free knowledge flow in the new paradigm known as Enterprise 
Social Networking (ESN) [2]; image and reputation promotion 
of enterprises and people within the enterprises; collaborative 
content creation via wikis, blogging or microblogging; infor- 
mation exchange with faithful and potential clients, partners, 
or competitors; search for candidates; etc. 

Unfortunately, along with the aforementioned personal and 
corporative benefits come several web-platform-dependant 
threats. As expected, with the expansion of OSN, both in and 
out the enterprise, they are becoming the favourite target for 
cybercriminals. Actually, in 2009, OSN were one of the main 
significant channels to identity theft and information leaking 
[31, [4], [51], [6]. Furthermore, spam sending and malware 
distribution through OSN are increasing at an incredible pace 


[7], [8]. 


The remainder of this paper is organised as follows: Sec. II 
provides a short introduction to Threat Modelling (TM); 
Sec. HI presents the assets at risk by OSN; Sec. IV details 
the attacks that are appearing against those assets through 
OSN; Sec. V discusses some of the countermeasures to be 
implemented against the previous attacks; finally, Sec. VI 
concludes and outlines the avenues of future work. 


TI. THREAT MODELLING 


Threat Modelling is a description of a collection of security 
aspects, a set of plausible attacks which are able to affect 
the performance of any computer system. This methodology 
allows security experts to identify security risks, verify an 
application's security architecture, and develop countermea- 
sures in the design, coding, and testing phases [9]. Therefore, 
analysing and modelling the potential threats that an applica- 
tion faces is an important step in the process of designing a 
secure application [10]. 
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Fig. 1. Threat Modelling's Circle of Risk. 

Being the main objective of threat modelling to provide 
useful guidelines on how to mitigate the associated risks, we 
must be able to distinguish the elements corresponding to what 
we have called the Circle of Risk (CoR) (shown in Fig. 1). 
The CoR is composed of assefs, which are compromised 
by threats; threats that exploit vulnerabilities, which when 
misused result in exposure, which represents a serious risk. 
Finally, the countermeasures mitigate the dangers caused by 
those risks; countermeasures which have as goal protecting the 
assets. Definitions for the aforementioned terms can be found 
within the technical dictionaries [11] and [12]. 
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Although the threat modelling process requires the study 
in detail of every above-mentioned element, in this paper we 
introduce a first approach to the CoR, focussing on the assets, 
attacks, and countermeasures. 


TIT. ASSETS AT RISK BY OSN 


Every organisation has at disposal several assets that must 
be protected to guarantee the proper course of its business. 
The loss, theft, destruction, reduction, or damage of any of 
these assets could prevent the organisation from achieving its 
objectives. Therefore, among the assets specially threatened 
by OSN we can identify [13]: 


1) Private information: it can be stolen or used against 1ts 
legitimate owner in order to harass, extort, or send hyper- 
contextual advertising. 

Financial assets: they can be stolen through on-line 
banking fraud, telephone fraud, or lost by decreased 
productivity. 

Intellectual property: it can be stolen, plagiarised, or 
illegally distributed free of charge, causing economic 
losses. 

Corporate secrets: their leakage or theft can cause eco- 
nomic losses, reputation damage, or decreased compet- 
itiveness. 

User's physical security: it can be compromised by 
stalkers, harassers, criminals, or thieves. 

Computing and network resources: they can be con- 
sumed leading to denial of service or decreased Quality 
of Service (QoS). 

Corporate and personal reputation: it can be irreversibly 
damaged. 

8) Digital identity: 1t can be spoofed or stolen. 
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In conclusion, the misuse of OSN affects the aforemen- 
tioned assets, which are compromised by the attacks described 
in the next section. 


IV. ATTACKS IN OSN 


OSN have concocted a dangerous cocktail of user-supplied 
content, open APIs, and web pages heavily loaded with 
JavaScript and embedded media of all descriptions. And it is 
an environment that is largely devoid of security standards and 
practices [14]. Since attacks are aimed at the aforementioned 
assets, this work introduces the potential attacks that affect 
OSN organised in categories corresponding to the objective 
they are oriented to. 


A. Private Information 


. Sensitive data retrieval: Attackers are able to collect 
users? personal data due to their negligence when pub- 
lishing private information [15], [16], [17]. 

Sensitive attribute inference models: The attributes of 
users who are connected in social networks are often 
correlated. Zheleva et al. [3] introduced different attacks 
to infer the hidden sensitive values: 


— Friend-Aggregate model (AGG): AGG looks at the 
sensitive attribute distribution amongst the friends of 
the person under question. 

- Collective classification model (CC): Unlike more 
traditional methods, in which each instance is clas- 
sified independently of the rest, collective classifi- 
cation aims at learning and inferring class labels of 
linked objects together. 

— Flat-link model (LINK): Another approach to deal- 
ing with links by “flattening” the data by considering 
the adjacency matrix of the graph. 

— Blockmodelling attack (BLOCK): The basic idea 
behind stochastic blockmodelling is that users form 
natural clusters or blocks, and their interactions can 
be explained by the blocks they belong to. 

— Groupmate-link model (CLIQUE): One can think 
of groupmates as friends to whom users are implic- 
itly linked. In this model, they assume that each 
group is a clique of friends, thus creating a friendship 
link between users who belong to at least one group 
together. 

— Group-based classification model (GROUP): An- 
other approach to dealing with groups is to consider 
each group as a feature in a classifier, inferring 
sensitive information according the groups a user 
belongs to. 

— BASIC In the absence of relationship and group 
information, the only available information is the 
overall marginal distribution for the sensitive at- 
tribute in the public profiles. So, the simplest model 
1s to use this as the basis for predicting the sensitive 
attributes of the private profiles. 

Data Mining for demographic information: Using data 
mining techniques to retrieve public demographic data 
[18], one could infer unpublished personal data about 
other users. 

Automated User Profiling: Retrieval of users sensitive 
data by querying social networks for registered e-mail 
addresses and crawling every profile found to collect 
personal information [19]. 

De-anonymise OSN users: It exploits group membership 
information that is available on social networking sites, 
which is often sufficient to uniquely identify users, or, at 
least, to significantly reduce the set of possible candidates 
[20]. 

OSN Mash-ups: Link data between independently pro- 
vided web services to obtain previously unforeseen infer- 
ences including highly personal information [21]. 

OSN Aggregators: Services that integrate several OSN 
which multiply vulnerabilities by giving read/write access 
to several social network accounts using a single weak 
authentication [21]. 


B. Financial Assets 


. Cross-Site Scripting (XSS): A type of computer security 
vulnerability typically found in web applications that 
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enables malicious attackers to inject client-side script into 
web pages viewed by other users [22], [21], [23]. 
Cross-Site Request Forgery (CSRF): Unlike XSS, which 
exploits the trust a user has for a particular site, CSRE 
exploits the trust that a site has in a user's browser [22], 
[23]. 

Bank-customer oriented Malware: In order to max- 
imise their monetary benefits, malware creators target 
bank customers credentials [24]. The appearance of these 
attacks has increased [25], due to the use of social 
networks as a distribution channel. A recent example 
is Koobface!, which upon successful infection, gathers 
sensitive information from the victims such as credit card 
numbers. 


C. Intellectual Property 


Contents publication property of third parties: It 
occurs when a user publishes the contents not being the 
legitimate holder of the intellectual property rights of 
such material [1]. 

Search engines indexation of protected contents entails 
a greater diffusion and therefore an exponential increased 
number of reproductions [1]. 

Loss of control over contents when users unsubscribe 
from the on-line service: OSN based on profiles elimi- 
nate, or at least block, all the contents associated to the 
profile of the user leaving the service, while in platforms 
based on contents, where members can get to publish 
works without being associated directly to their profile, 
material may remain publicly accessible [1]. 


D. Corporate Secrets 


Social Engineering: Manipulating people into perform- 
ing actions or divulging confidential information using 
information found in OSN profiles [26]. 

Spear Phishing: Spear phishing appears genuine to all 
the employees or members within a certain company, 
government agency, organisation, or group, using infor- 
mation found in OSN profiles [27]. 


E. Physical Security 


Location Inferring from recognisable places in the im- 
age [28] or connection IP [29]. 

Facial Recognition: Sophisticated facial recognition al- 
gorithms used to identify unknown users [30]. 
Harassment between Adults Bullying via electronic 
communication tools [31], [32]. 

Cyber-bullying Harassment via electronic communica- 
tion tools from child to child [31], [32]. 
Cyber-grooming (harassment from adult to child) 
Sexual exploitation of children on-line [33]. 


Ihttp://news.cnet.com/koobface-virus-hits-facebook/ 


FE. Computing and Network Resources 


. Spam and Hyper-contextualised Advertising: Spam 
1s becoming a major issue for OSN, and the use of 
hyper-contextualised advertising (1.e. adapt advertising to 
users preferences) increases the possibility of the junk 
messages being read [21]. 

+. Botnets: Attacks designed solely to disable infrastructure 
to those that also target people and organisations.[34]. 


G. Corporate and Personal Reputation 


+. Sybil Attacks: Given a reputation system, a peer may 
attempt to falsely raise its reputation by creating fake 
identities — or sybils — and using them to its benefits 
[35]. 

. Classes of attacks against reputations systems: Hoff- 
man et al. [36] classify attacks against reputation systems 
based on the goals of the reputation systems. 

— Self-promoting: Attackers manipulate their own rep- 
utation by falsely increasing it. 

— Self-Serving or Whitewashing: Attackers escape 
the consequence of abusing the system by using 
some system vulnerability to repair their reputation. 
Once they restore their reputation, the attackers can 
continue the malicious behaviour. 

— Slandering: Attackers manipulate the reputation of 
other nodes by reporting false data to lower their 
reputation. 

— Orchestrated: Attackers orchestrate their efforts and 
employ several of the above strategies. 

— Denial of Service (DoS): Attackers may cause denial 
of service by either lowering the reputation of victim 
nodes so they cannot use the system or by prevent- 
ing the calculation and dissemination of reputation 
values. 


H. Digital Identity 


+. Credentials Theft by technical hacking techniques [37]. 

. Profile Cloning consists of identifying a victim and 
creating a new account with his real name and photograph 
inside the same social network [38]. 

. Cross-site Profile Cloning identifies victims who are 
registered in one social network, but not in another and 
steals their identities creating accounts for them in the 
network where they are not registered [38]. 

Finally, it is important to take into account that the danger 
level of one attack is directly proportional to how dangerous 
the vulnerability being exploited is and inversely proportional 
to the effectiveness of the deployed countermeasures. 


V. MAJOR COUNTERMEASURES IN OSN 


Countermeasures reduce the vulnerabilities in a system. In 
this section, we present these countermeasures grouped into 
the following main categories: platform countermeasures and 
user countermeasures. The former refers to countermeasures 
which collaborative platforms must implement in order to 
prevent attacks directed both to platforms and users, while the 
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later intends to introduce the best practices to improve users 
privacy habits. 


A. Countermeasures addressed to the Platform 


1) Technological Security of the Platform: System admin- 
istrators of collaborative networks should be aware that their 
users share personal data through their services. Therefore, 
they should protect their networks against potential attacks, 
employing tools especially made to combat against pharming 
and phishing [39] cases, not to mention one of the most 
annoying threats of the current times: the spam?. Regarding 
network connections, they should make use of secure connec- 
tions applying technologies (e.g. Security Socket Layer (SSL) 
[40]), to ensure private data transmissions. 

On the other hand, OSN provide users with little control 
over their personal data. As a consequence, identity theft 
and fake profiles are common issues. These platforms should 
provide tools to prevent cases of identity theft, to allow 
legitimate users to get back the control of the account after the 
theft, or to strengthen user identification before registration. 
Additionally, it is recommended to implement technological 
measures to verify the age of the users, in order to protect 
children against inappropriate contents or behaviours. 

2) User's Data: OSN need to facilitate access to the Terms 
of Service and User Conditions displaying all the information 
in understandable terms. To this end, these documents must 
employ a perfectly understandable language by any kind of 
user. After reading the document, the user should know its 
rights and obligations during the use of the service. 

Besides, OSN must guarantee the users a complete control 
over their published information. Therefore, a social network 
must implement several procedures in order to satisfy the 
following: 


+. Users should know the intended use by the social network 

of both personal and published data. 

+. Users should be able to apply the rights to access, rectify, 

cancel, and oppose to data concerning them published in 

the OSN. 

+. User profile configuration should default to maximum pri- 

vacy, allowing to later changing it according to personal 

preferences. 

+ Users should be able to prevent the publication of unau- 
thorised data. The use of tagging mechanisms requesting 
user's approval is one of the approaches aimed at the 
achievement of this goal. 


Furthermore, OSN must protect users data against the 
indexation of search engines by using appropriate codification. 

3) Author's royalties protection: Author's rights must be 
protected. OSN must provide users with tools that allow 
reporting the existence of contents protected by author's rights. 
Additionally, social networks need adequate staff or automatic 
tools, such as Digital Right Management tools, anti-copy 
systems, or watermarks, to check all uploaded contents and 
establish if such contents are subject to intellectual rights. 


?http://blog.facebook.com/blog.php?post=40218392130 


Besides, OSN users must know the nature of the rights to 
authorship and the importance to respect them for the correct 
use of the service, through general conditions when creating 
new accounts, FAQs, etc. 

4) User Awareness: Users should be informed about the 
use that social networks make of their personal data, the ad- 
vertisement systems present in the platform, and the potential 
threats that users face while using on-line services. Similarly, 
it is necessary to display information related to the security of 
the platform, including the measures that users should take in 
case of abuse of their rights. 


B. Countermeasures addressed to the Users 


1) User's Behaviour: The user must read the Terms of Use 
and Privacy Policies of the OSN, both before the registering 
process and every time any change occurs. Once the user has 
registered, it must configure properly the privacy settings, so 
that only his friends have access to the published contents. 

Users have absolute control over the information that they 
want to publish inside the OSN. They are therefore responsible 
for the publication of excessive information putting at risk their 
intimacy or their whereabouts. In this sense, it is mandatory 
to raise the users awareness into a rational publishing of 
their personal information. However, users should be aware 
that some information is out of their control, for example 
when published by other users of the same OSN, by public 
organisms, such as Boletín Oficial del Estado (BOE), or public 
registries. 

Moreover, friendship relations are the core of these net- 
works. Once defined the privacy settings, users must be careful 
with friend requests. Users should only accept friend requests 
coming from people already known and avoid accepting com- 
pulsively any request for friendship because it could result in 
privacy issues. 

2) Technological Concerns: There are security and tech- 
nological considerations that users must take into account in 
order to increase the level of security. First, users should use 
different user-names and passwords to access different social 
networks. Second, they should use strong passwords to prevent 
brute force attacks. Finally, they should use updated security 
software and operating system. 

3) Special Considerations for Children: Under-age users 
are specially vulnerable. Thus, they need extra care to ensure 
that their personal data is not disclosed. Parents or guardians 
should be consulted for every sensitive action when using so- 
cial networks (e.g. content uploading and publishing personal 
information), being able to abort their children actions. 

Additionally, parents and guardians should take into account 
several considerations. The computer should be placed in a 
common area of the house, establishing some rules about the 
use of Internet. Parental control and content-blocking systems 
should be installed and effectively working, and minors should 
be aware of the dangers that OSN might represent. 


VI. CONCLUSION 


On-line Social Networks represent one of the last and most 
important Internet services. Albeit most enterprises hesitate 
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whether to ignore completely the OSN, this new phenomenon 
can not be ignored, but neither can be integrated into the 
business model without knowing the risks. In this paper, 
we presented a first approach to an OSN Threat Modelling 
that discovers the first elements to take into account when 
attempting to protect a system. To that end, we identify the 
assets at risk, the attacks that can compromise them, and we 
propose some countermeasures to protect against these attacks 
(the mapping attack-countermeasure is provided in Table )). 
In this table we can appreciate that the number of different 
attacks outnumbers the countermeasures, which indicates that 
a good level of security can be assured by following some 
simple guidelines. In addition, the analysis of the attacks and 
countermeasures shows that user's good practice is the main 
objective in order to achieve more secure OSN. 

The future work of this OSN TM is oriented in three 
main directions. First, we will complete the aforementioned 
“Circle of Risk” (see Fig. 1), with the exposures that suffer the 
assets and the risks that represent them. Second, we plan on 
developing a taxonomy which organises all the existing OSN 
threats, attacks, vulnerabilities, and countermeasures. Finally, 
we will study the feasibility of adding weighted variables to 
the taxonomy in order to help identifying assets at risk and, 
hence, supporting the hardening of a system. 
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Resumen—En la actualidad, cada vez son más frecuentes los 
ataques software mediante la utilización de malware o sustitución 
de programas (o componentes) en los repositorios a los cuales 
los usuarios finales (o máquinas) acceden. Esta situación se ve 
de alguna manera acentuada con el dinamismo existente en 
la programación y ejecución de estos componentes, en la que 
distintos desarrolladores pueden participar para desplegar un 
determinado servicio o parte de él. 

Por ello, en este artículo se presenta una solución para la 
distribución de código de forma segura usando OpenID y firmas 
con certificados de clave pública de corta duración. De esta forma, 
se consigue un compromiso de seguridad que permite distribuir 
código firmado sin la necesidad de que los desarrolladores 
dispongan a priori de un certificado específico. Presentamos 
además algunos detalles acerca de la implementación realizada 
para hacer realidad este diseño. 


L. INTRODUCCIÓN Y OBJETIVOS 


La distribución segura de componentes software es en la 
actualidad un factor crítico para todos los usuarios, y no 
sólo para las empresas desarrolladoras. Cada vez son más 
frecuentes los ataques software mediante la utilización de mal- 
ware o sustitución de programas (o componentes software) en 
los repositorios a los cuales los usuarios finales (o máquinas) 
acceden. Esta situación se ve de alguna manera acentuada por 
el dinamismo intrínseco en la programación y ejecución de 
estos componentes software, en la que distintos desarrolladores 
pueden participar para desplegar un determinado servicio (o 
partes de él). 

Es muy conocido el imparable aumento del malware en todo 
el mundo. En especial en nuestro país que, según el informe 
del primer trimestre de este año 2010 de PandaLabs [1], ocupa 
la primera posición en el ranking de países con respecto al 
número de ordenadores infectados. Según estas estadísticas, 
al menos uno de cada tres ordenadores están infectados por 
algún tipo de malware. Por ello es especialmente importante 
bloquear en todo momento la capacidad de propagación del 
mismo. 

Dado el aumento de prestaciones de los dispositivos 
móviles, existe una aplicación disponible para prácticamente 
cualquier necesidad, y aquí la integridad del software o la 
confianza en el desarrollador son objetivos fundamentales a 
perseguir. La proliferación de aplicaciones disponibles para 
todo tipo de dispositivos y para los dispositivos móviles 
en particular, ha provocado por añadidura que sean cada 
vez más el numero de desarrolladores que distribuyen estas 


aplicaciones. No todos ellos deben tener el mismo nivel de 
confianza sino queremos que el malware encuentre una puerta 
de entrada a nuestros sistemas. 

Este escenario se vuelve más importante cuando pen- 
samos en el futuro: Multitud de dispositivos, posiblemente 
autónomos, interconectados entre sí y conectados al “exterior”, 
siendo así actores del Internet of Things, y ejecutando servicios 
cuyo código y composición puede cambiar de forma dinámica, 
y en los que la instalación y desinstalación de los distintos 
componentes que construyen el servicio en ejecución se ha de 
realizar en tiempo real. 

Existen soluciones que permiten decir a nuestro sistema 
que sólo ejecute componentes firmados y que además esta 
firma sea confiable (nuestro sistema ha de confiar en alguno 
de los certificados existentes en el camino de verificación 
de la firma). Pero no escapa a los usuarios finales (ni a 
los desarrolladores) que estas soluciones transforman a los 
sistemas en ocasiones en demasiados restrictivos, haciendo 
que en muchos casos, los administradores de estos dispositivos 
terminen por cancelar este tipo de comprobaciones. 

Por otra parte, los desarrolladores, se ven abocados a 
soportar una burocracia digital, para en todo momento, contar 
con certificados digitales no caducados y firmados por una 
entidad confiable. Este proceso es relativamente sencillo y 
natural para grandes empresas desarrolladoras de software. Sin 
embargo, no ocurre lo mismo para desarrolladores particulares 
que carecen de medios. En los ambientes móviles el uso 
de código firmado está muy extendido y aunque algunas 
plataformas como Symbian proporcionan mecanismos para la 
creación de certificados de desarrollo [2], este proceso requiere 
de un registro previo del desarrollador y la validez del código 
firmado está restringida al teléfono de desarrollo registrado. 

Esta situación se agrava en entornos en los que los servicios 
(programas en ejecución) se componen de forma dinámica 
y en tiempo real de distintos módulos o componentes, tal y 
como ocurre en la plataforma OSGi [4]. La plataforma OSG1 
es un sistema de módulos y servicios para el lenguaje de 
programación Java que implementa un modelo completo y 
dinámico de componentes. Las aplicaciones o componentes 
(en forma de bundles) pueden ser instaladas de forma remota, 
iniciadas, detenidas, actualizadas y desinstaladas sin necesidad 
de reiniciar. La gestión del ciclo de vida se realiza a través de 
APIs que permiten la descarga remota de políticas de gestión. 
El Registro de Servicios permite a los bundles detectar la 
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adición o la supresión de los servicios, y adaptarse en conse- 
cuencia. Las especificaciones OSGi se han movido más allá del 
enfoque original, y ahora se utilizan en aplicaciones que van 
desde teléfonos móviles al IDE de Eclipse [5], pasando por 
un amplio espectro de áreas de aplicación tan heterogéneas 
como pueden ser los automóviles, la automatización industrial 
y la automatización de edificios, dispositivos móviles como las 
PDASs, el ocio y el entretenimiento, la gestión de flotas o los 
servidores de aplicaciones. 

Así, el escenario que se presenta (ver Figura 1 para más 
detalles) es el de un dispositivo que soporta OSG1 que con 
el objeto de lograr la ejecución dinámica de componentes 
cuenta con conexión constante a distintos repositorios OSG1 
de los que cargará los distintos bundles de acuerdo a las de- 
pendencias y necesidades de los bundles actuales en ejecución. 
Nuestra solución ha de tener en cuenta los puntos de vista y 
necesidades de este dispositivo y de los desarrolladores para 
proporcionar integridad y confianza a la hora de ejecutar estos 
componentes a la par que facilidad de uso y sencillez a la hora 
de subir estos componentes a los repositorios. 
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Figura 1. Amenazas en el proceso de desarrollo de bundles 


TI. REQUISITOS 


Las amenazas a la seguridad para el despliegue de los 
bundles [6] pueden ser de tres tipos: 


1. La presencia de repositorios maliciosos para la publi- 
cación de bundles. 

2. Ataques “Man in the Middle”, de forma que un atacante 
pueda modificar un bundle o sustituirlo completamente 
por otro durante la carga o la descarga. 

3. La posibilidad de que un atacante acceda al repositorio 
de bundles o a la plataforma cliente para modificar los 
componentes almacenados en ellos. 

Tras el análisis del escenario y sus principales amenazas, 

los principales requisitos que pueden extraerse del mismo son 
los siguientes: 


1. Sencillez. 
2. Movilidad / portabilidad. 


3. Autenticación del desarrollador. 

4. Integridad de los bundles. 

5. Generación de firmas seguras. 

Se pretende conseguir una plataforma sencilla y robusta 


para la firma de componentes software. El impacto para el 
desarrollador (en términos de tiempo y complejidad) que sube 
un bundle a un repositorio OSGi ha de ser mínimo, sin que ello 
dificulte el proceso de verificación por parte de los usuarios! 
O dispositivos. 

Al no requerirse el uso de certificados personales para la 
distribución de los bundles se permite cierta movilidad de 
los desarrolladores, ya que pueden subir los bundles a los 
repositorios OSG1 simplemente accediendo al repositorio con 
su usuario y contraseña habitual. 

Es importante considerar que en el modelo de desarrollo 
de software libre, el conjunto de desarrolladores es dinámico 
y que la implicación de estos en el proyecto es variable. Por 
tanto se tiene que dar cabida no solo a los desarrolladores 
estables sino también a los eventuales que solo quieren aportar 
su granito de arena al proyecto. Por este motivo se define 
en mecanismo de autenticación para el repositorio basado en 
federación de identidades, de forma que el repositorio no tenga 
que autenticar directamente al desarrollador sino que sea 
su proveedor de identidad el que proporcione la información 
necesaria. 

En la solución propuesta se utilizan certificados temporales 
(de vida corta) generados a partir del conjunto de atributos 
que definen la identidad de desarrollador proporcionado por 
el proveedor de identidad para firma el código y por tanto 
proporcionar integridad de éste. Además, al ser certificados 
temporales, pueden ser utilizados desde cualquier dispositivo 
independiente de su situación geográfica y evitando la impli- 
cación en seguridad que tendría llevar consigo siempre un par 
de claves pública y privada para la firma de estos componentes. 

El uso de una federación de identidad permite que el 
desarrollador solo tenga que autenticarse de la misma manera 
(y con los mismos credenciales) que lo hace en otros servicios 
para poder almacenar un bundle firmado. Por supuesto, el 
repositorio OSGi cuenta con políticas de autorización que de- 
terminarán la visibilidad de estos bundles para otros usuarios, 
aunque consideramos este proceso fuera del ámbito de este 
trabajo. 

Para la generación de firmas de forma segura por parte 
del usuario, esta plataforma permitirá al usuario generar el 
par de claves de forma local y será el repositorio OSGi quien 
haga la función de tercera parte confiable que certifique esas 
claves, y que certifique que su usuario legítimo es quien 
dice ser. Este esquema difiere del sistema de distribución de 
paquetes de Debian [3], donde los repositorios pueden firmar 
sus paquetes permitiendo su posterior verificación, ya que en 
nuestro esquema para la verificación de un bundle el filtro de 
confianza se hace a nivel de desarrollador y no de repositorio. 


lEstos usuarios, potencialmente, pueden ser a su vez desarrolladores que 
trabajen de manera colaborativa en la implementación de bundles. 
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TI. COMPONENTES DE LA PLATAFORMA 
HFA. Bundles 


Un bundle no es más que un fichero JAR (Java Archive) que 
contiene además un conjunto de metadatos que especifican 
las características del componente. Estos metadatos están 
incluidos dentro del archivo MANIFEST.MF. Por tanto: 

Bundle = archivo JAR + MANIFEST.MF con metadatos 

Es necesario proporcionar algún tipo de soporte para el ciclo 
de vida de los bundles, desde la instalación hasta la ejecución 
y el borrado, por lo que la seguridad deberá contemplarse a 
lo largo de todo el ciclo de vida. 


IHIFB. Repositorio OSGi 


Se trata del repositorio en el que se almacenan los distintos 
bundles al que las máquinas que cuenten con plataformas de 
ejecución OSGI acceden para descargar componentes. De la 
misma manera, los desarrolladores suben estos bundles una 
vez testeados o con el objetivo de colaborar en el desarrollo 
de los mismos. 

El administrador del repositorio ha de autenticar a todos los 
desarrolladores que pretendan almacenar bundles y a su vez 
facilitar la integridad de estos componentes, de forma que se 
enlace de manera inequívoca cada bundle con cada uno de 
sus autores. Para ello, la plataforma proporciona un servicio o 
autoridad de certificación (CA) cuyo único objetivo es permitir 
la firma de los mismos. 

Ciertamente, este servicio de certificación podría ser ex- 
terno, y reconocido, pero dado que los certificados han de ser 
temporales y de una funcionalidad muy reducida, el repositorio 
puede ejercer esta función, reduciendo así el proceso previo a 
la firma por parte de los desarrolladores. 


IFC. Servidor OpenID 


OpenID [7] es un sistema de autenticación digital descen- 
tralizado, con el que un usuario puede identificarse en una 
página Web a través de una URL (o un XRI en la versión 
actual) y puede ser verificado por cualquier servidor que 
soporte el protocolo. En los sitios que soporten OpenID, los 
usuarios no tienen que crearse una nueva cuenta de usuario 
para obtener acceso. En su lugar, solo necesitan disponer 
de un identificador creado en un servidor OpenID (OpenID 
provider), es decir, un proveedor de identidad OpenID (IdP). 

Este proveedor de identidad puede confirmar la identifi- 
cación OpenID del usuario a un sitio que soporte este sistema. 
A diferencia de arquitecturas SSO (Single Sign-On), OpenID 
no especifica el mecanismo de autenticación. Por lo tanto, la 
seguridad de una conexión OpenID depende de la confianza 
que tenga el cliente OpenID en el proveedor de identidad. 
Si no existe confianza en el proveedor, la autenticación no 
será adecuada para servicios bancarios o transacciones de 
comercio electrónico. Sin embargo, el proveedor de identidad 
puede usar autenticación fuerte si el proveedor de servicio 
(Service Provider) así lo requiere. 

De entre los atributos que proporciona OpenID (ver [7] 
para más detalles), se han seleccionado los siguientes para 
la generación de los certificados temporales: 


1. openid.extl.value.firstname (en adelante, firstname) 
2. openid.extl.value.lastname (en adelante, lastname) 
3. openid.extl.value.email (en adelante, e-mail) 

4. openid.op_endpoint (en adelante, ID provider) 


Con la elección de OpenID, se pretende evitar la central- 
¡zación que supone un sistema jerárquico de PKI, que restaría 
dinamismo a la plataforma e introducirían una dependencia 
sobre la disponibilidad de la jerarquía de CA para la gen- 
eración de certificados. En otras palabras, logramos con ello 
evitar la necesidad de acudir presencialmente a una Autoridad 
de Registro. 


1FD.  Applet de firma 


Para la firma y creación de los certificados de firma digital se 
requiere la descarga y ejecución por parte del desarrollador de 
del applet de firma. El applet de firma solo toma como entrada 
del usuario el repositorio de destino, así como el bundle que 
se quiere firmar. 

La estructura de clases [9] que presenta el código fuente del 
applet es la que se muestra en la Figura 2 


JarSignerApplet 


FIRMA SUBIDA 


utiliza utiliza 
l Y 


JarSigner 


JarUploader 


utiliza utiliza 


¡ | 5 


ManifestDigester SignatureFile org.apache.commons.httpclient 


Figura 2. Estructura de clases que utiliza el applet de firma 


Como apoyo auxiliar para la firma de bundles se han 
utilizado dos herramientas proporcionadas por Java: Jarsigner 
y Keytool. 

La herramienta Jarsigner [10] tiene dos objetivos princi- 
pales: firmar archivos JAR y verificar la firma y la integridad 
de archivos JAR firmados. Para ello, utiliza información de 
certificados y claves que obtiene a partir de un almacén de 
claves (keystore). Un keystore contiene una de base de datos 
con claves privadas y las cadenas de certificados X.509 que 
autentican sus correspondientes claves públicas. 

La herramienta Keytool [11] se encarga de la gestión de 
claves y certificados, de forma que permite a los usuarios 
administrar sus propias claves públicas y privadas y los 
certificados asociados a éstas para autenticarse a sí mismo 
frente a otros usuarios o servicios o para realizar verificaciones 
de integridad mediante las firmas digitales. 

Un usuario se puede encontrar con dos tipos diferentes de 
entradas que formarán parte de un almacén de claves: 
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1. Claves: Una clave almacenada suele ser una clave 
privada acompañada de la correspondiente cadena de 
certificación de su clave pública 

2. Certificados de confianza: Los certificados de confianza 
son aquellos certificados de clave pública de otro usuario 
o entidad de los que se conoce con certeza la identidad 
de su propietario 

Existen otras opciones de Keytool para importar en el key- 

store certificados ya existentes, para exportar certificados, para 
generar certificados autofirmados o para generar solicitudes 
CSR que serán firmadas posteriormente por una CA, opción 
ésta de la hemos hecho uso en la implementación. 


IV. PROCESOS DE LA PLATAFORMA 


El objetivo final de esta plataforma es la distribución segura, 
mediante un repositorio, de componentes software. Para ello, 
se utilizará la información de identidad proporcionada por 
un servidor OpenID? para crear unos certificados temporales, 
que serán firmados por un servicio de CA online del propio 
repositorio y serán utilizados para la firma del bundle, como 
paso previo a la carga en el repositorio. 


IV-A. Proceso de firma de un bundle 


La solución planteada para proporcionar seguridad en los 
bundles es la firma digital, que por las peculiares característi- 
cas de los bundles, se debe almacenar dentro del bundle, junto 
al resto de componentes. Los archivos relacionados con la 
firma de un bundle son los siguientes: 


1. Un archivo de manifiesto (Manifest File), que contiene 
un listado con el valor hash de cada uno de los recursos 
del bundle. 

2. Para soportar varias firmas, la firma digital no se aplica 
directamente sobre el archivo de manifiesto, sino sobre 
un archivo para la firma denominado (Signature File) 
que contiene un valor hash del archivo de manifiesto. 
Hay un archivo de firmas por cada firmante. 

3. La firma digital del archivo de firmas se almacena 
en un archivo CMS (Content Management System) 
denominado Block Signature File. La extensión de este 
archivo es el nombre del algoritmo de firma (.dsa, .rsa, 
entre otros). Además, este archivo contiene los datos 
necesarios para la verificación de la firma, como es la 
cadena de certificados que verifican al usuario firmante, 
que en nuestro caso será la cadena formada por el 
certificado temporal creado con los atributos OpenID del 
usuario y el certificado de clave pública de la CA online 
del repositorio OSGi. 


En nuestra implementación, el orden de estos recursos 
dentro del bundle es el que aparece descrito anteriormente. 
Todos estos ficheros se colocarán delante del resto de recursos 
del bundle. Este orden será uno de los aspectos que se tendrán 
en cuenta durante el proceso de verificación de un bundle 
firmado. 


2En nuestras pruebas se han utilizado con éxito, los servidores OpenID de 
Google, RedIRIS y Yahoo. 


En la Figura 3 se muestra la interacción entre los compo- 
nentes de la plataforma. El flujo de información en el proceso 
de firma de un bundle paso por paso sería el siguiente: 


= El desarrollador se conecta al servicio de subida de 
bundles del repositorio (Bundle Upload Service). 

= El primer paso será acceder a la URL de descarga del 
applet. Al acceder a esta URL se comprueba si el usuario 
accede con atributos OpenID y, en caso de no llevarlos, es 
redirigido a un servicio WAYF (Where Are You From). 

= El servicio WAYF permitirá al usuario seleccionar su 
proveedor de identidad OpenID, hacia el que será redi- 
rigido. 

= El usuario introducirá su usuario y contraseña para auten- 
ticarse en el servidor OpenID, lo que permitirá que éste 
servidor envíe los atributos OpenID del usuario hacia la 
página de redirección, que será la URL de descarga del 
applet. 

= En un segundo acceso a la URL de descarga del applet, 
si la comprobación de atributos OpenID se realiza con 
éxito se permite que se inicie el proceso de descarga. 
En el navegador del usuario, se pedirá la autorización 
del usuario para la ejecución del applet a partir de la 
confianza en el certificado del desarrollador del mismo. 

= A partir de los atributos OpenID con los que se ini- 
cializará el applet, se generan un par de claves pública 
y privada y la correspondiente solicitud CSR (Certificate 
Signing Request). Los campos necesarios para las claves 
se cumplimentarán de la siguiente manera: 


Common Name: firstname + lastname 
Organization Unit: e-mail 
Organization: ID provider 

Country: ES 


= El CSR se envía al servicio de la CA online del reposi- 
torio. 

= El servicio de la CA online generará un certificado de 
clave pública a partir del CSR y la clave privada de la 
CA. 

= La CA online envía el certificado de clave pública, junto 
al certificado de clave pública de la CA si fuera necesario. 
En el applet, se unen el certificado de clave pública y 
la clave privada y el usuario ya tiene la capacidad para 
firmar componentes software con un certificado temporal 
completo. 

= Se realiza el proceso de firma del bundle a partir del 
certificado temporal obtenido y se envía el bundle al 
repositorio. 


La principal razón para la elección de un applet como 
elemento central de la plataforma en el proceso de firma es 
que el par de claves pública y privada se deben generar de 
forma local en el equipo del usuario (para que el desarrollador 
realmente confíe en las claves generadas), pero a partir de un 
software existente en la plataforma. 

De esta forma, el usuario se descarga el applet en el 
navegador y autoriza su ejecución (confiando en su autor) 
durante el proceso automático de descarga del mismo. La se- 
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Figura 3. 


guridad de este applet y como el usuario deposita su confianza 
autorizando su ejecución es un problema resuelto que por lo 
tanto queda fuera del ámbito de este trabajo. 


IV-B. Proceso de verificación de un bundle firmado 


El proceso de verificación se realiza de forma simétrica al 
proceso de firma consta de los siguientes pasos: 


1. El primer paso será validar la identidad del firmante, 
para lo que habrá que verificar la cadena de confianza del 
certificado, que sólo estará formada por el certificado de 
clave pública de la CA online del repositorio, verificando 
también que dicha CA se encuentra en el almacén 
de certificados de confianza (truststore). Además, se 
deberán mostrar los atributos del certificado temporal, 
para que el cliente decida si confía en el proveedor de 
identidad OpenID que proporcionó los atributos con que 
se generó el certificado temporal. 

2. El segundo paso de la verificación consiste en comprobar 
s1 los recursos dentro del bundle siguen el orden descrito 
en las especificaciones: archivo de manifiesto, archivo de 
hash (Signature File), archivo de firma (Block Signature 
File) y resto de archivos del bundle 

3. El tercer y último paso será verificar la coherencia de 
los archivos de metadatos [8]: el archivo de firma debe 
contener una firma válida del archivo de hash, el archivo 
de hash debe contener un valor hash válido para el 
archivo de manifiesto y el archivo de manifiesto debe 


Arquitectura de la plataforma 


contener el nombre y valor hash de todos y cada uno de 
los recursos del bundle 
En nuestra implementación hemos decidido que la veri- 
ficación de la firma se haga en el mismo repositorio, de 
manera que se incorpora el resultado de dicha verificación 
en la vista que se muestra al usuario de forma que pueda 
decidir que en bundles deposita su confianza de forma que no 
supongan una sobrecarga para el dispositivo que va a ejecutar 
los bundles. Obviamente, esto implica que deba haber una 
relación de confianza con el servlet del repositorio que se 
encarga de esta función de verificación de firma si bien en 
nuestra esquema siempre suponemos que el repositorio es 
confiable. En cualquier caso, el usuario podrá descargar la 
firma junto con el bundle y verificarla localmente para un 
mayor nivel de seguridad. 
Por tanto podemos describir el proceso de la autenticidad 
de los bundles desde el punto de vista de la siguiente manera: 
= El cliente se conecta al servicio que muestra el listado 
de bundles disponibles en el repositorio 
= Por cada bundle, el repositorio deberá mostrar: 
e Los atributos propios del bundle, como pueden ser 
el nombre, el tamaño o la fecha de creación 
e La identidad OpenID del desarrollador/firmante del 
bundle 
e El proveedor de identidad OpenID (ya que el cliente 
deberá decidir si es de confianza o no) 
e La CA que certifica dichas identidades, 
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e Algún tipo de mensaje de error en caso de que se 
produzca algún tipo de error durante el proceso de 
verificación. 


= Viendo esta información, será misión del cliente decidir 
si se descarga el bundle y lo ejecuta o no.? 


V. CONCLUSIONES Y TRABAJO FUTURO 


En la actualidad es una máxima que la distribución de 
software debe de tener en cuenta durante todo su ciclo 
la seguridad. Entre otros aspectos se deben proporcionar 
mecanismos para evitar ataques de sustitución de software (o 
componentes) con el objetivo crítico de impedir la propagación 
de malware (y, por supuesto, todas las consecuencias nefastas 
que éste lleva asociado). 

La plataforma OSGi tiene en la distribución de componentes 
software, así como en la actualización, instalación y desinsta- 
lación de manera dinámica, autónoma y en tiempo real, su 
mejor exponente. Nos sirve pues este escenario para desarrol- 
lar una plataforma de distribución de bundles (componentes 
software en OSGi) segura. 

Sin embargo, el diseño de la plataforma es generalizable a 
cualquier escenario de distribución de ficheros (aplicaciones, 
componentes software, imágenes, etc.) donde el la identidad 
del propietario sea un factor crítico. La ventaja de nuestro 
esquema sobre los sistemas tradicionales de firma de código 
es su flexibilidad y facilidad de uso ya que solo requiere 
que el desarrollador se autentique frente al repositorio usando 
un proveedor OpenID favorito. Si bien no se elimina la 
necesidad de confiar en el repositorio, tal y como ocurre con 
la distribución de paquetes en sistemas tipo Debian, se añade 
un grado adicional de seguridad al certificarse la identidad 
del propietario mediante la firma del bundle con el certificado 
temporal creado a partir dos atributos proporcionados por el 
proveedor de identidad. 

En la actualidad estamos trabajando en una migración de 
esta plataforma hacia otros escenarios, y considerando las im- 
plicaciones, sobre los terminales en particular y la plataforma 
diseñada en general, de aumentar los niveles de seguridad de 
este diseño (por ejemplo mediante el uso de CAs externas para 
la generación de certificados). 

Otro aspecto que estamos considerando es la definición de 
extensiones para los certificados X.509v3 generados de forma 
que la cookie de autenticación OpenID o parte de ella se pueda 
incluir en el certificado temporal de firma. 
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Abstract—Este artículo describe la infraestructura SEREN- 
ITY ' para el mantenimiento y evolución de soluciones de seguri- 
dad y dependabilidad (S£D) obtenidas dinámicamente. También 
se presentan las características principales de la infraestructura 
junto con los diferentes mecanismos que lo conforman y, final- 
mente, se describe un escenario para ilustrar la aplicación de la 
infraestructura presentada. 


I. INTRODUCCIÓN 


La aparición de sistemas altamente distribuidos que operan 
en ambientes heterogéneos y frecuentemente en condiciones 
de cambios de contexto (por ejemplo sistemas móviles, sis- 
temas basados en servicios, inteligencia ambiental, etc..), 
plantean retos significativos para los sistemas de seguridad y 
dependabilidad (S8D). Esto hace necesario desarrollar mecan- 
ismos que soporten la configuración dinámica, el desarrollo, 
la monitorización y la evolución de Sé£D Solutions. Con 
estos ajustes, el mantenimiento dinámico y fluido se con- 
vierte en un elemento central para asegurar la seguridad y 
dependabilidad de los sistemas, manteniendo las soluciones 
actualizadas y asegurando que son usadas correctamente. El 
proyecto SERENITY ha desarrollado mecanismos que sopor- 
tan el desarrollo dinámico, la configuración y monitorización 
de SéD Solutions que cumplen las propiedades de seguridad 
genéricas y de dependabilidad y se describen usando modelos 
llamados SéD Patterns. El modelo SERENITY se centra en 
la provisión y supervisión de SéD Solutions en tiempo de 
ejecución, permitiendo la detección de problemas en instancias 
individuales de SéD Solutions y la reconfiguración automática 
de las aplicaciones usando estas soluciones. Para aumentar 
la confianza en las Sé£D Solutions es necesario analizar su 
comportamiento cuando se usa en diferentes contextos. Un 
análisis dinámico global puede detectar situaciones que no 
son posibles de detectar con un análisis dinámico local o 
estático, tales como problemas en las implementaciones, en los 
modelos que los describen o incluso problemas causados por 
la interacción de soluciones diferentes. Los resultados de este 
análisis proveen una base para la toma de acciones que puede 
soportar el mantenimiento y evolución de S£D Solutions en 
respuesta para identificar problemas. Este artículo describe 


ITrabajo realizado parcialmente en los proyectos SERENITY (FP6-IST- 
027587) y DESEOS (TIC-4257) 


la extensión del marco de trabajo SERENITY que soluciona 
este propósito, la Infraestructura de Evolución SERENITY. 
El objetivo de la Infraestructura de Evolución SERENITY es 
analizar problemas detectados en las operaciones de S£D So- 
lutions a un nivel global para soportar la reacción automática, 
evolución y mantenimiento de aplicaciones operando en sis- 
temas altamente dinámicos y heterogéneos. Para conseguir 
este objetivo, debemos tener en cuenta que por eficiencia y 
limitaciones de ancho de banda no es posible reenviar todos los 
eventos recibidos desde las diferentes soluciones. De hecho, 
las razones de seguridad, de dependabilidad y de privacidad 
hacen inaceptable reenviar todos los eventos a monitores remo- 
tos. Por estas razones, hemos desarrollado una infraestructura 
de tres capas. La primera capa de la infraestructura usa 
información de violaciones de reglas generada por el marco 
de monitorización de SERENITY [1]. Una segunda capa, 
con objetivo de controlar los problemas relacionados con la 
interacción de diferentes soluciones en una plataforma dada y 
dirigida por un componente llamado Agente Transparente. Por 
último, una tercera capa controla la operación de soluciones 
específicas que corren en diferentes plataformas, basados en 
Metamonitores específicos para cada solución. Empezando por 
las reglas de monitorización locales, la infraestructura está 
diseñada para evaluar la integridad de las SéD Solutions y 
para dar soporte al mantenimiento del sistema, permitiendo 
a los administradores del sistema y los desarrolladores de 
soluciones mejorar estas soluciones basándose en el compor- 
tamiento observado. Como se mencionó, para realizar este 
objetivo la infraestructura recoge, agrega y analiza información 
sobre las violaciones de diferentes propiedades a través de 
distintas instancias del marco SERENITY y las aplicaciones 
que ofrece. El resto de este artículo está organizado de la 
siguiente manera. La Sección 2 presenta trabajos relacionados 
y un transfondo para el modelo SERENITY. La Sección 
3 presenta la infraestructura de mantenimiento y evolución 
SERENITY. En la Sección 4 se describe un escenario de 
aplicación. Por último, la Sección 5 presenta las conclusiones 
y trabajo futuro. 


TI. TRANSFONDO Y TRABAJO RELACIONADO 


La infraestructura que presentamos ha sido desarrollado en 
el último año del proyecto SERENITY. Debido a la novedad 
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del modelo de sistema seguro y dependable definido en el 
proyecto, no hay otra infraestructura que ofrezca las mismas 
características que ofrecemos nosotros en este artículo. Por 
esta razón, no se encuentran muchos trabajos relacionados en 
esta sección. De hecho, se ofrece algunos enfoques parcial- 
mente relacionados. Además, se ofrece una introducción al 
modelo SERENITY de sistemas de computación seguros y 
dependables. 


A. Trabajos relacionados 


El mantenimiento de software es un conjunto de actividades 
realizado en un sistema software para su uso operacional. 
Las encuestas han mostrado que, para muchos proyectos, el 
mantenimiento de software consume la mayoría del coste 
del ciclo de vida, y hay indicaciones de que los costes de 
mantenimiento aumentan proporcionalmente. La detección de 
violaciones de propiedades esperadas son el punto de inicio 
del mantenimiento de actividades en el desarrollo software 
[2]. El trabajo en las arquitecturas de mantenimiento es difícil 
y obsoleto [3]. Las tecnologías de mantenimiento [4], 
[5] tienden a ignorar la primera fase de la actividad de 
mantenimiento, la detección de errores. Además, como en 
cualquier desarrollo, la confianza en las SézD Solutions que 
están disponibles y pueden ser usadas a través del marco 
de trabajo SERENITY es un prerrequisito fundamental. A 
pesar del reconocimiento de la importancia y necesidad en 
la confianza en interacciones humanas e intercambios y, como 
consecuencia, el reciente incremento del volumen de la liter- 
atura en este tema (por ejemplo [6], [7], [8], [9]), la confianza 
está actualmente pobremente evaluada para los propósitos de 
desarrollo dinámico de software. Además, ninguna de estas 
hebras de trabajo soluciona correctamente algunos aspectos 
importantes de la confianza en el servicio software, como en el 
caso de las S£D Solutions de SERENITY, basándose no solo 
en Opiniones subjetivas si no también en información adquirida 
dinámicamente sobre el comportamiento y calidad de los ser- 
vicios software en diversos contextos de desarrollo. Además, 
cada valoración de la confianza debería estar acompañada por 
una evaluación de su precisión y riesgo [10]. 


B. El modelo SERENITY para sistemas seguros y dependables 


El objetivo de esta sección es facilitar el entendimiento 
del modelo subyacente que usamos como base en nuestro 
trabajo. Sin embargo, debido al tamaño y complejidad, está 
fuera del objetivo de este artículo dar una completa visión de 
SERENITY. El lector interesado puede consultar la referencia 
[1] para una descripción comprensiva del sistema completo. 
El proyecto SERENITY ofrece un marco de trabajo para 
el tratamiento automático de las cuestiones de Seguridad 
y Dependabilidad (SéD) en los escenarios de Inteligencia 
Ambiental (Aml) concentrándose en dos puntos: (1) capturar 
la maestría específica de los ingenieros de seguridad de tal 
forma que permita su procesamiento automático; y (11) ofrecer 
medios para realizar selección, monitorización y reemplazo 
de mecanismos de seguridad y dependabilidad en tiempo de 
ejecución. Estos dos puntos han sido desarrollados por medio 


de un conjunto de componentes, descritos a continuación. 
En SERENITY, el pilar fundamental para construir solu- 
ciones seguras y dependables es el concepto de SéD Pattern 
(Patrón SéD). Existen cinco artefactos para representar de una 
forma lógica SézD Solutions en el proyecto SERENITY: SéD 
Classes, SéD Patterns, Esquemas de Integración (Integration 
Schemes), SéD Implementations y Componentes Ejecutables 
(Executable Components). Estos artefactos representan S8éD 
Solutions usando descripciónes semánticas a diferentes nive- 
les de abstracción. La razón principal para usar diferentes 
artefactos, cada uno para un distinto nivel de abstracción, 
es porque de esta forma es posible cubrir el ciclo de vida 
completo de las aplicaciones de seguridad, especialmente en 
las fases de desarrollo y de ejecución. Los SéD Patterns 
son descripciones precisas de SézD Solutions abstractas. Estas 
descripciones contienen toda la información necesaria para la 
selección, instanciación, adaptación y aplicación dinámica de 
la solucion representada en el SéD Pattern. Están compuestos 
de diferentes elementos los cuales describen las funcionali- 
dades de los patrones de seguridad y como usarlos. Desde 
el punto de vista de su implementación, los elementos mas 
interesantes de la estructura de los SéD Pattern son: (1) la 
interfaz del patrón, la cual describe las funcionalidades del 
SézD Pattern y como usarlos; (11) las SéD Classes a las cuales 
pertenece el SéD Pattern (ver abajo); y (111) el ClassAdaptor. 
Los SéD Patterns incluyen descripciones de como adaptar 
la interfaz del S8D Pattern al interfaz del SéD Class. Los 
SéiD Patterns representan soluciones monoliticas de SéD 
Solutions, aunque existe un tipo especial de S£D Solution 
llamado Integration Scheme (Esquema de Integración), el 
cual consiste en un SézD Solution que está al mismo nivel 
que los SézD Patterns. Representan SézD Solutions que son 
construidas para ser combinadas con otros SézD Patterns. 
Cuando se está desarrollando una aplicación, los Integration 
Schemes se usan de forma similar a como lo hacen los SéD 
Patterns. Sin embargo, difieren en su proceso de desarrollo. 
A lo largo de este documento se referirá tanto a los SéD 
Patterns como a los Integration Schemes como SéD Patterns 
indistintamente. Las SézD Classes representan abstracciones 
de un conjunto de SéD Patterns caracterizados por proveer 
las mismas S8D Properties y poseer una interfaz común. Este 
es uno de los artefactos mas interesantes usados en tiempo 
de desarrollo por los desarrolladores de sistemas. El propósito 
principal de este artefacto es facilitar la sustitución dinámica 
de las SéD Solutions en tiempo de ejecución a la vez que 
facilita el proceso de desarrollo. Las Sé£D Implementations 
representan los componentes que implementan las SézD Solu- 
tions. Estos artefactos no son implementaciones reales si no 
que representan una descripción de la implementación. Estos 
componentes son accesibles a las aplicaciones a través del 
SRF. Un SézD Implementation describe una implementación 
de un SéD Pattern. Un SézD Pattern puede tener mas de una 
SézD Implementation. Finalmente, los Executable Components 
son las implementaciones de las SéxD Implementations. Estos 
elementos no son usados en tiempo de desarrollo pero son 
la implementación real de la Sé£D Solution. Un Executable 
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Component funciona como una SéD Solution ejecutable que 
provee sus servicios de SéD a las aplicaciones. En tiempo 
de ejecución el SRF es capaz de activar, desactivar y adaptar 
los Executable Components dependiendo de los requisitos de 
SéD de las aplicaciones. Los SéD Classes, S8¿D Patterns 
y S£D Implementations son artefactos orientados al tiempo 
de desarrollo y los Executable Components están especial- 
mente diseñados para ser usados en tiempo de ejecución. 
Dependiendo del nivel de abstracción del artefacto usado por 
un desarrollador de aplicaciones, en tiempo de ejecución el 
SRF es mas flexible cuando selecciona las SézD Solutions. 
El propósito principal de introducir este esquema es facilitar 
la sustitución dinámica de las S£D Solutions en tiempo de 
ejecución a la vez que se facilita el proceso de desarrollo. Estos 
nuevos conceptos pueden ser útiles de dos formas diferentes: 
en tiempo de diseño/desarrollo y en tiempo de ejecución. 
En el primer caso, debemos considerar que las aplicaciones 
grandes desarrolladas hoy en día se construyen integrando 
soluciones de distintas fuentes y en diferentes niveles de 
abstracción. Estas aplicaciones se enfrentan a la existencia 
de amenazas y errores que pueden requerir mantenimiento. 
El lector puede encontrar los detalles de como implementar 
aplicaciones SERENITY y SéD Solutions en [12]. Usando 
el enfoque SERENITY, este mantenimiento se realiza con un 
esfuerzo mínimo, incluso automáticamente y sin errores. En el 
segundo caso (por ejemplo en tiempo de ejecución), los S£D 
Patterns se usan para ofrecer una adaptación automática de los 
mecanismos SéD al realizar cambios de contexto. Para con- 
seguir este objetivo, es necesario tener un marco de trabajo que 
ofrezca el manejo de una librería de patrones y la evolución 
constante de tales patrones, teniendo en cuenta el contexto en 
el cual se aplican. El SERENITY Runtime Framework (SRF) 
es capaz de seleccionar la S£D Solution mas apropiada entre 
las disponibles, basándose en los requisitos de los usuarios y 
el contexto actual. 


TIT. INFRAESTRUCTURA DE MANTENIMIENTO Y 
EVOLUCIÓN DE SERENITY 


La arquitectura propuesta se basa en el Runtime Sup- 
port Model (modelo de apoyo en tiempo de ejecución) de 
SERENITY. En este modelo, las aplicaciones cuentan con 
el SRF [1] para que les proporcione las S£D Solutions que 
necesiten. Para permitir el mantenimiento y evolución de estas 
soluciones, y por tanto de las aplicaciones que las usan, se ha 
diseñado una arquitectura multicapa que proporciona todos los 
mecanismos necesarios para realizar procesos de verificación 
dinámica. Intríinsecamente a estos mecanismos se encuentra el 
concepto de transparencia. Cada SézD Pattern está diseñado 
para garantizar su correcto funcionamiento por medio de la 
monitorización en tiempo de ejecución. Para llevar a cabo esto, 
en la descripción de un patrón se especifican unas reglas de 
monitorización. En el caso de los patrones de SERENITY es- 
tas reglas se expresan usando EC-Assertion [13]. EC-Assertion 
es un lenguaje de lógica temporal de primer orden basado en 
el Cálculo de Eventos. Las reglas de monitorización en este 
lenguaje tiene la forma B => H, donde se declara que si B 


es verdadero, H debe serlo también. Ambos B (Cuerpo) y 
H (Cabeza) son definidos como conjunciones de predicados 
en el Cálculo de Eventos. Los predicados que se usan en las 
reglas de monitorización expresan la ocurrencia de un evento 
(predicado Happens), el comienzo o fin de una condición por 
medio de la ocurrencia de un evento (Predicados de Inicio y 
Fin respectivamente), o la validez de una condición (predicado 
HoldsAt). Los predicados se asocian a variables de tiempo 
que indican el momento en el que el predicado es Verdadero. 
Los eventos en el EC-Assertion puede que representen in- 
vocaciones de operación y respuestas, o señales y mensajes 
generados durante el funcionamiento de un sistema, y están 
ligadas a una variable de tiempo. La descripción detallada del 
EC-Assertion no forma parte del objetivo de este artículo, y 
puede ser encontrada en [13]. Un ejemplo de una regla de 
monitorización expresada en EC-Assertion es: 

(_idl, 

_sender, 

_receiver, 

REO, 


decrypt (_x,_y), 
_receiver), 


Happens (e 


tl, 
R(t1,t1)) 
> 
Happens (e (_id2, 
_receiver, 
_sender, 
RES, 


decrypt (_xX,_y)» 
_receiver), 

t2, 

R(t1,t1+1000) 


Esta regla expresa una propiedad de disponibilidad obliga- 
toria para una operación de descifrado decrypt (_x, _y) que 
descifra una cadena de entrada _x y genera otra de salida _y. 
Según la regla, después de la invocación de una operación 
decrypt en el componente de descifrado _receiver en algún 
momento tl, debe haber una respuesta al invocador de la 
operación (_sender) en algún momento t2 no más tarde de 
1000 milisegundos tras tl. La restricción temporal para la 
respuesta a la invocación se indica en el rango de tiempo de 
la variable t2 del evento de respuesta que, como se indica 
en la regla es R(t1,t1+1000) (por ejemplo, (t1,t1+1000)). La 
reglas de monitorización en los SécD Patterns deben estar 
diseñadas para proporcionar la información requerida por la 
aplicación, la cual usa el patrón para evaluar el correcto 
funcionamiento del patrón y de los Componentes Ejecutables 
que lo implementan. En un sistema en funcionamiento, los blo- 
ques básicos de construcción son los Componentes Ejecutables 
(ECs), los cuáles son implementaciones de los Sé£D Patterns. 
Los Componentes Ejecutables deben incluir Capturadores de 
Eventos para informar a sus clientes sobre su funcionamiento 
interno. Por lo tanto, es de obligado cumplimiento para todas 
las implementaciones de un S8D Pattern, incluir código para 
capturar los eventos utilizados en las reglas de monitorización 
del patrón y notificar estos eventos a la aplicación a través del 
SRF. 
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Fig. 1. 


Arquitectura de evaluación y mantenimiento de SERENITY. 


Cuando el SRF recibe un evento de un EC, este evento 
es gestionado por el mecanismo de monitorización de la 
plataforma. En este caso, el evento es reenviado al servicio 
de monitorización oportuno, el cual evalúa el estado actual 
del EC aplicando las reglas de monitorización definidas en 
el S8D Pattern correspondiente. Si se detecta la violación de 
alguna regla, se informa sobre ello al SRF, el cual registra 
la violación y toma las acciones apropiadas. Estas acciones 
pueden ser: desactivar un patrón, pausarlo, resetearlo, etc. 
En [14] podemos encontrar una descripción detallada. Para 
tratar con posibles problemas causados por la interacción 
entre distintos ECs, existe un segundo mecanismo de moni- 
torización encargado de monitorizar a nivel de una plataforma 
SERENITY en concreto. El Agente de Transparencia sirve a 
este propósito realizando un análisis horizontal. En concreto, 
analiza los datos provenientes de distintos ECs que se están 
ejecutando en la misma máquina. El Agente de Transparencia 
recoge información relacionada con las violaciones de las 
reglas de monitorización, las analiza y envía los resultados 
al Metamonitor. Los resultados enviados dependen de ciertas 
reglas, de manera que es el administrador del TA el que decide 
qué información se envía al Metamonitor y qué información 
permanece como secreta. Para permitir la evolución de SéD 
Solutions específicas y detectar problemas tanto de imple- 
mentaciones incorrectas, como de problemas en el modelado, 
existen elementos específicos llamados Metamonitores que 
llevan a cabo un análisis vertical. Estos analizan información 
que procede de distintas máquinas sobre la misma S£D 
Solution. Los Metamonitores reciben información de distintos 
Agentes de Transparencia y realizan un nuevo análisis de estos 
datos. Por tanto, el Metamonitor posee un visión global de 
como es el comportamiento de las distintas SézD Solutions en 
contextos diferentes, y es capaz de deducir las conclusiones 
apropiadas. La existencia de Metamonitores beneficia no solo 
a los usuarios de las soluciones sino que también a los 
desarrolladores de las mismas. 


A. Elementos de Mantenimiento de la Evolución 


El propósito principal de la Infraestructura de Evolución 
de SERENITY es posibilitar la formulación de cálculos de 
confianza basados en la información obtenida en tiempo de 
ejecución sobre el comportamiento de los componentes que 
implementan los SézD Patterns y SéD Solutions. El Agente 


de Transparencia (TA) se asocia a una aplicación cliente es- 
pecífica que hace uso de SéD Solutions a través de una instan- 
cia particular de la plataforma SERENITY. El objetivo del TA 
es el de recoger información relacionada con las violaciones 
de reglas de monitorización en el contexto de la aplicación 
cliente con la que se encuentra asociada, y analizar dicha infor- 
mación para identificar problemas relacionados con los casos 
particulares del uso de SéD Solutions. Los resultados del 
análisis realizado por el Agente de Transparencia son puestas a 
disposición del administrador local del sistema, el cual poste- 
riormente puede actuar en consecuencia, y realizar cambios a 
nivel local, normalmente serán cambios en la configuración de 
la aplicación cliente y la plataforma SERENITY local. Estos 
resultados también pueden ser enviados al Metamonitor para 
permitir un análisis de distintas plataformas SERENITY. El 
Metamonitor (MM) está bajo el control del proveedor de una 
determinada SéD Solution, y se ejecuta en una infraestructura 
externa. El MM recibe los resultados de los análisis que 
han realizado los distintos Agentes de Transparencia de los 
distintos SRFs, que usan esa S£D Solution particular. El 
cometido principal del MM es analizar las violaciones de 
las reglas de seguridad de una determinada S£%D Solution 
(y su correspondiente SéD Pattern) en distintos contextos 
operacionales, y usar ese análisis para sugerir posibles formas 
de mejorar dicha solución y/o el patrón que la describe. 
Ejemplos de este tipo de análisis incluyen comparaciones del 
número de violaciones de reglas de monitorización de distintas 
SézD Solutions, que implementan el mismo patrón en contex- 
tos operacionales diferentes o la identificación de puntos en 
común en condiciones de contexto operacionales. El análisis 
del MM proporciona la base para la formulación de cálculos de 
confianza de S8D Patterns y SéD Solutions que se ejecutan 
en distintos contextos operacionales y que pueden dar lugar a 
tomar decisiones como la modificación en la descripción de un 
SáD Pattern, la desactivación de determinadas Sé£D Solutions 
que están violando las condiciones de ejecución establecidas 
por el SézD Pattern en distintos contextos, etc. 


IV. ESCENARIO DE APLICACIÓN 


Para poner de manifiesto el uso de la infraestructura de 
evolución de SERENITY consideramos el escenario en el 
que dos aplicaciones que se ejecutan en dos empresas difer- 
entes necesitan intercambiar información confidencial. Ex- 
plicar como construir estos elementos está fuera del alcance de 
este artículo, pero puede ser consultado en [1]. Cada empresa 
tiene un nodo SERENITY que contiene un SRE, aplicaciones 
locales, SéD Solutions, Monitores locales y un Agente de 
Transparencia. Las SéD Solutions son monitorizadas para 
detectar violaciones en las reglas a través de los eventos 
detectados y enviados por los Componentes Ejecutables. Los 
Agentes de Transparencia monitorizan a las SéD Solutions 
locales y envían sus estadísticas a los Monitores (que son 
solution-specific) donde las reglas violadas son analizadas. 
Para construir este escenario se han desarrollado las SéxD 
Solutions necesarias y las aplicaciones que usan las empresas 
para el intercambio de información entre ellas. Las SéD 
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Solutions están almacenadas en el SRF local de cada empresa. 
Las aplicaciones solicitan a estos SRFs SéD Solutions, y 
obtienen Componentes Ejecutables que implementan dichas 
soluciones. Los ECs son monitorizados por medio de los 
eventos que envían al SRF. Estos eventos poseen información 
sobre el estado del funcionamiento de estos ECs y pueden 
informar al SRF cuando una regla en violada. El SRF almacena 
eventos en un log de eventos, de manera que es el Agente 
de Transparencia local el que accede al mismo. Parte de esta 
información es reenviada a los Metamonitores. Supongamos 
que de forma repetida recibimos en el TA violaciones sobre 
regla x en EC A y regla y en EC B. Si la frecuencia de 
estas violaciones es estadísticamente significativa, se podría 
concluir que existe una interacción inusual en estos dos ECs y 
en consecuencia tomar las medidas apropiadas (como corregir 
ambos ECs o detectar la incompatibilidad en la descripción 
de sus Sé£D Patterns). Ahora imaginemos que el Metamonitor 
recibe de forma repetida violaciones de un regla por parte del 
EC A indicando una transición ilegal entre dos estados. Esto 
indicaría que el EC A no se ajusta al modelo del SézD Pattern 
al que corresponde. Por otro lado sí las violaciones provienen 
de distintos ECs del mismo SéD Pattern, esto indicaría un 
error en el modelo del SéD Pattern. Toda esta información 
puede ser enviada a los desarrolladores de una determinada 
SézD Solution de manera que les sea útil a la hora de corregir 
posibles fallos de dicha solución. Una vez la mejora haya sido 
realizada, el gestor de seguridad de SERENITY puede notificar 
a los nodos cliente para que eliminen, actualicen o agreguen 
una nueva solución de seguridad que mejore el rendimiento 
de la que se está usando. 


V. CONCLUSIONES Y TRABAJOS FUTUROS 


Este artículo ha presentado la infraestructura de SEREN- 
ITY para el mantenimiento y evolución de componentes de 
seguridad y dependabilidad, y de las aplicaciones que las usan, 
en escenarios de computación dinámica. Esta infraestructura 
añade dos niveles de monitorización más por encima del mod- 
elo base de monitorización de SERENITY para proporcionar 
soporte al mantenimiento y evolución de estas soluciones 
y aplicaciones. Actualmente, los resultados de los análisis 
realizados por la Infraestructura de Evolución se ven reflejados 
en el comportamiento del SRF a través de cambios realizados 
de forma manual por un administrador encargado de esta tarea. 
Como trabajo futuro nuestros esfuerzos van dirigidos a la con- 
secución de la reacción automática por parte del SRF acorde 
a los análisis realizados por la Infraestructura de Evolución. 
Otra línea interesante de investigación actualmente iniciada 
es la identificación de cambios que deben ser aplicados a un 
componente cuando un problema es detectado. 
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Abstract— Nowadays, web applications are target of numerous 
and varied attacks and their protection is indispensable. In 
this paper, a simple and effective web application firewall is 
presented. The system follows an anomaly-based approach, in 
order to detect both known and unknown web attacks. The 
system decides whether the incoming requests are attacks or 
not aided by an XML file, which contains a description of the 
target web application normal behavior. The XML file defines the 
features and patterns that valid values of the different elements 
in the HTTP requests should satisfy. Two models has been built 
to characterize the features: a model based on the argument 
lengths, and a model based on the character distribution using 
Markov Chains. All input requests that deviate from the defined 
normal behavior are considered anomalous, and rejected by the 
system. 

The system has been tested using a large set of artificially- 
generated HTTP requests (both normal and anomalous) targeting 
a deliberately vulnerable web application. The experiments show 
that if the XML file has enough data to closely characterize 
the normal behavior of the target web application, a very high 
detection rate is reached while the false alarm rate remains very 
low. 


IT. INTRODUCTION 


Web applications are becoming increasingly popular in all 
sorts of environments, ranging from e-commerce applications 
to banking. Additionally, web applications handle lot of sen- 
sible data, and as a consequence they are subject to all sort 
of attacks, many of which may be devastating [1]. In order 
to protect against web-specific attacks, the detection is to be 
moved to the application layer. 

An Intrusion Detection System (IDS) analyzes information 
from a computer or a network to detect malicious actions and 
behaviors that can compromise the security of a computer 
system [2]. Traditionally, IDS”s have been classified as either 
signature detection systems (also called negative approach) or 
anomaly detection systems (positive approach). 

The first method looks for signatures of known attacks 
using pattern matching techniques against a frequently updated 
database of attack signatures. It is unable to detect new 
attacks and in order to work properly, databases must be 
updated frequently. Signature matching usually requires high 
computational effort. 

The second method overcome these problems, although 
it is prone to more false positives. It looks for anomalous 
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system activity: once normal behavior is well defined, irregular 
behavior will be tagged as intrusive. A disadvantage is that 
in rather complex environments, obtaining an up-to-date and 
feasible picture of what “normal” network traffic should look 
like proves to be a hard problem. 

Web Application Firewalls (WAE) analyzes the HTTP traffic 
in order to detect malicious behaviors that can compromise the 
security of web applications [3]. 

In this paper, an effective anomaly-based Web Application 
Firewall (WAF) is presented. This system relies on an XML 
file to describe what a normal web application is. Any irregular 
behavior is flagged as intrusive. The XML file must be tailored 
for each target application to be protected. 

Regarding related works, [4] presents an overview of differ- 
ent anomaly detection techniques. Additionally, some works 
focused on the attack detection in web traffic have been 
presented: in [5] Kruegel et al. use a parameter-oriented 
URL format and apply several anomaly-detection models to 
detect possible attacks. In [6] Markov chains are used for the 
detection and [7] is an anomaly-based system which infers 
the type of the request parameters and combines different 
techniques to detect attacks. Also, ModSecurity [8] is a known 
commercial WAF which follows a signature-based approach. 

The rest of the paper is organized as follows. In Sec. Il, a 
system overview is shown, where system architecture, normal 
behavior modeling, and attack detection are explained. Section 
TIT refers to experiments. Traffic generation, the training phase, 
the test phase and results are also described. Section IV 
describes system limitations and suggests future work. Finally, 
in Sec. V, the conclusions of this work are captured. 


TI. SYSTEM OVERVIEW 
A. Architecture 


Our anomaly-based detection system analyzes HTTP re- 
quests sent by a client browser trying to get access to a web 
server. The analysis takes place exclusively at the application 
layer. 

In our architecture, the system operates as a proxy located 
between the client and the web server. Likewise, the system 
might be embedded as a module within the server. However, 
the first approach enjoys the advantage of being independent 
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of the web platform. A diagram of the system's architecture 
1s shown in Fig. 1. 

The input of the system consists of a collection of HTTP 
requests [r],r2,...rn). The output is a single bit a; for each 
input request r;, which indicates whether the request is normal 
or anomalous. The proxy is able to work in two different 
modes of operation: as an IDS and as an IPS. 

In detection mode, the proxy simply analyzes the incoming 
packets and tries to find suspicious patterns. If a suspicious 
request is detected, the proxy launches an alert; otherwise, it 
just lets the request continue the way to the server. In any 
case, the request will reach the web server. When operating in 
detection mode, attacks could succeed, whereas false positives 
do not limit the system functionality. 

In prevention mode, the proxy receives requests from clients 
and analyzes them. If the request is valid, the proxy routes it to 
the server, and sends back the server”s response to the client. 
Tf not, the proxy blocks the request, and sends back a generic 
denegation access page to the client. Thus, the communication 
between proxy and server is established only when the request 
is deemed as valid. 


Client 


HTTP Req. HTTP Req. 


RN 


HTTP Resp. HTTP Resp, e 


Fig. 1. 


Web Application Firewall Architecture 


B. Normal Behavior Description 


Prior to the detection process, the system needs a precise 
picture of what the normal behavior is in a specific web 
application. For this purpose, our system relies on an XML file 
which contains a thorough description of the web application's 
normal behavior. Once a request is received, the system 
compares it with the normal behavior model. If the input 
request does not match the criteria in the XML, it is flagged 
as an attack and an alert is launched. 

The XML file contains rules regarding to the correctness 
of HTTP methods, HTTP headers, accessed resources, and 
arguments. This file contains three main nodes: 

Methods: The methods node simply specifies the list of 
allowed HTTP methods. Requests using any other method will 
be rejected. 

Headers: The headers node specifies a list of the admitted 
HTTP headers and a description of their values. For each 
header found in the normal input requests, a rule node is 
included in the XML file. The rule node contains information 
about the header name (attribute name) and its description 
model (subnodes length and markovModel). 


Directories: The directories node has a tree-like structure, 
in close correspondence to the web application's directory 
structure. 


1) Each directory in the web application space is repre- 
sented in the XML file by a directory node, allowing 
nesting of directories within directories. The attribute 
name defines these nodes. 

2) Each file in the web application space is represented by 
a file node within a directory node and is defined by its 
attribute name. 

3) Input arguments are represented by argument nodes 
within the corresponding file node. The attribute name 
is used to define these nodes. 

4) In the same way as header values, some properties are 
used to describe the expected values of the argument. 
Therefore, every argument node has the length and the 
markovModel nodes, with their corresponding attributes. 
Argument values not meeting the length or the Markov 
model criteria will be rejected. 


The adequate construction of the XML file with the suitable 
properties is crucial for a good detection process. An example 
of XML configuration file is shown in Fig. 2. 


<configuration> 
<methods> 
<method>GET</method> 
<method>POST</method> 
</methods> 
<headers> 
<rule name="Accept-Language"> 
<length lowerLimit="0" upperLimit="2"/> 
<markovModel A="1.0" Pi="1.0" states="1"/> 
</rule> 
</headers> 


<directories> 
<directory name="shop"> 
<file name="index.jsp"/> 
<directory name="public"> 
<file name="features.jsp"> 
<argument name="id"> 

<length lowerLimit="0" upperLimit="2"/> 
<markovModel A="1.0" Pi="1.0" states="d"/> 
</argument> 


</file> 
</directory> 
</directory> 
</directories> 


Fig. 2. XML file example 


C. Detection Models 


In order describe the normal behavior of the arguments and 
headers, two detection models have been used. The first model 
is based on the attribute length, and the second one is based 
on its structure. 
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1) Attribute Length: The length of an argument, query 
attribute or header can be used to detect anomalous requests. 
Many web attacks (code injection, XSS, buffer overflow, etc.) 
use a considerable amount of input characters. On the other 
hand, normal requests do not usually contain many bytes. 

The system uses a model to learn the normal length dis- 
tribution for each parameter or header. The model consist of 
the following. First, we assume that the length of the values 
for a given input falls into a normal (gaussian) distribution. 
Second, percentile of the distribution is used to determine a 
threshold. All lengths that exceed the established threshold are 
not allowed. 

During the training, some statistical properties are collected 
to describe the normal input length distribution. After col- 
lecting the statistical properties, an allowed length interval 
is calculated, and included in the XML file within the tag 
<length>. 


(0,5 + Zscore * 9] 


. The lower limit is set to O, since it has no sense to restrict 
the lower length limit. 

+. The upper interval is the percentile of the distribution, 
with a given probability. The percentile p is one of the 
parameters of the model. In our approach the values 
0.90,0.95,0.99 were used. (see Sec. III). 


2) Attribute Structure: The structure of the arguments and 
the headers is also very useful in order to detect anomalous 
requests. In our approach, a model based on Markov Chains 
has been used to describe this structure. 

A Markov chain is defined by a set of N states T' = 
(S1,52,...,Sy) and by the pair of probability matrices (II, 
A). The matrices express the temporal evolution of the system 
from a statistical point of view. A good text for about Markov 
chains is [9]. 

During the training, three features are collected to describe 
the model: the states string, II and A. These features are 
included in the XML within the tag <markovModel>. 

The knowledge about the different states reached by the 
system is obtained from the observation of the training values. 
These observed states Q) = O; can take one or more of these 
values: / (letters), d (digits) and the rest of printable ASCH 
characteres (like *,(.),-/, etc.). Letters are grouped in the 
state / and digits in the state d. From our knowledge about 
web attacks, we think that by grouping letters and digits, the 
detection results will be very similar and reducing the number 
of states, the efficiency of the system increases. Matrices II 
and A will only have the states of those characters that indeed 
appeared in the training set for the corresponding element. 

The matrix TI = 1Vi € [1,N] is a vector that indicates the 
probability of the ¡-th state being the first of the temporal 
sequence of observations. 

The matrix A represents the transition probabilities between 
states. A=A¡¡Vi, j € [1,N]: given that the system is in the state 
i at some time £, probability of it reaching the state ¡ at time 


1 +1. The matrix of transition probabilities can be estimated 
by 


P(qi+1 NN O;,q1 = O;) 

P(q: =0;) 
In the previous formula it is considered that the state of any 
trial depends on the state of the directly preceding trial, and 
only on this state. 

The two probabilistic terms in the previous expression can 
be calculated by counting the number of appearances of the 
symbol in the corresponding training values. Similarly, Pi 
can be estimated counting how many times the corresponding 
symbol is the first one in the observed training value. 

Section I-D describes when an input value matches the 
model. Input values not matching the given model will be 
rejected. 


dij= 


D. Detection Process 


In the detection process, our system follows an approach 
of the form “deny everything unless explicitly allowed”. The 
detection process consists of several steps, each constituting 
a different line of defense, in which the proxy checks the 
different parts of the input request aided by the XML file. 
If an incoming request fails to pass one of these lines of 
defense, an attack is assumed. Requests considered as attacks 
are logged for further inspection. It is important to stress that 
these requests will never reach the web server when operating 
in prevention mode. The detection process is composed of the 
following steps: 

1) Method checking. The method must be present in the 
XML file, otherwise the request is rejected. For example, 
in the applications in which only GET, POST and HEAD 
are required to work correctly, the XML file could be 
configured accordingly, thus rejecting requests that use 
any other method. 

Header checking. If the header appears in the XML 
file, its value must match the length and Markov model 
criteria. If any header of the request is not valid, it is 
not accepted, thus preventing attacks embedded in these 
elements. 

Resource checking. The system checks whether the 
requested resource is valid. For this purpose, the XML 
configuration file contains a complete list of all files that 
are allowed to be served. If the resource in the request 
is not present in the list, a web attack is assumed. 
Argument checking. If the request has any argument, the 
following aspects are checked: 
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a) Allowed arguments. If the request includes argu- 
ments not listed in the XML file for the correspond- 
ing resource, an illegal manipulation is assumed 
and thus the request is rejected. 

b) Argument values. An incoming request will be 
allowed if the actual argument values are identified 
as normal. For each argument in the request, the 
actual value is compared with the corresponding 
Length and Markov models, which describe the 
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normal behavior of the argument. If a single argu- 
ment value does not match the models, the whole 
request is rejected. 

For evaluating whether a given observed value is 
recognized by the previously estimated Markov 
model, the following approach has been adopted: 
Given a Markov chain A = (4,TT) and a sequence 
of observed symbols O = 01,0»,...,Or, the se- 
quence is recognized by the Markov chain if the 
probability of the sequence being generated by 
the Markov chain (P[O|A]) exceeds an stablished 
threshold. 

A useful measure for this purpose is the represen- 
tation on a logarithmic scale of the Maximum A- 
posteriori Probability (MAP): 


T-1 
LogMAP(O,h) =log(To,) + Y, log(a0,0,,1) (1) 

=1 
In this measure, no probability can be zero. A usual 
technique to solve this is performing a previous 
smoothing of the Markov model. A simple way of 
smoothing the model is setting those probabilities 
lower than a given threshold, to a fixed value e. 
While the observations corresponds to the ones 
expected by the model, the function "LogMAP” (1) 
will have no abrupt changes of slope. However, 
if there is any unexpected symbol, there will be 
an abrupt change of the slope. To detect these 
changes and thus the anomalies in the input, the 
following function, which is an approximation of 
the derivative of the function 'LogMAP”, can be 
used: 


W 
Dy(t) =|LogMAP(t) — a Y LogMAP(t—i)| (2) 
i=1 
where W is the window size, and can take values 
W=1,2,3,.... The second term in (2) is the mean 
of the last W outputs. 
(2) supplies an output for each symbol analyzed 
in the sequence. When the output exceeds a fixed 
threshold 7, an anomaly is detected. 
Different experiments have been performed vary- 
ing the values of the parameters e and T (see 
Sec.IIL-E and HI-P). 

The steps explained before allow the detection of both static 
attacks, which request resources that do not belong to the 
application, and also dynamic attaks, which manipulate the 
arguments of the request. 


TII. EXPERIMENTS 


A. Case Study: Web Shopping 


The WAF has been configured to protect a specific web 
application consisting of an e-commerce web store, where 
users can register and buy products using a shopping cart. 


B. XML File Generation 


As already stated, the XML file describes the normal 
behavior of the web application. 

The names of the different elements of the request (method, 
headers name, resources and argument names) are obtained 
from the values in the training set. Therefore, to train the 
system and to correctly configure this file, only normal and 
non-malicious traffic to the target web application is required. 

Nevertheless, how to obtain big amounts of only normal 
traffic may not be an easy task, considering that to obtain 
significative detection results, a large amount of requests are 
needed. There are several alternatives to obtain normal traffic: 


1) Thousands of legitimate users can surf the target web 
application and generate normal traffic. However, this 
may not be easy. 
The application can be published in the Internet. In that 
case, attacks will be mixed with normal traffic with a 
very high probability. As explained before, our aim is 
that only normal requests features are included in the 
XML file. The better the normal behavior is described, 
the better the results. 
When working with real traffic, two alternatives can 
be considered. Either the training phase is performed 
with the real traffic or the real traffic is filtered before 
the training phase. The disadvantage of the first option 
is that real traffic probably contains attacks, thus the 
system will learn these requests as normal ones and these 
attacks will not be detected. Filtering the traffic could 
be very useful, even though it is necessary to be careful 
as filtering too much could delete normal requests that 
should be included in the normal description of the web 
application. Performing a good filtering phase and using 
a big amount of requests could be a good solution for 
an adequate training. 
3) Traffic can be generated artificially. Although the traffic 
is not real, we can be sure that only normal traffic is 
included. 
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For the e-commerce web application, we considered the 
third alternative as the most suitable for our purposes hence 
artificial traffic has been generated for this web application. 


C. Artificial Traffic Generation 


In our approach, normal and anomalous request databases 
were generated artificially with the help of dictionaries. 

1) Dictionaries: Dictionaries are data text which contain 
real data to fill the different arguments used in the target appli- 
cation. All the dictionaries used (names, surnames, addresses, 
etc.) were extracted from real databases. 

A set of dictionaries containing only allowed values was 
used to generate the normal request database, and a different 
set containing attacks and illegal values was used to generate 
the anomalous request database. 

2) Normal Traffic Generation: Allowed HTTP requests 
were generated for each page in the web store. Arguments and 
cookies in the page, if any, were also filled out with values 
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from the normal dictionaries. The result was stored in database 
called NormalDB containing the normal requests. 
3) Anomalous Traffic Generation: Ilegal HTTP requests 
targeting the web store were also generated with the help of 
anomalous dictionaries. The result was stored in the anomalous 
request database AnomalousDB. 
Three types of anomalous requests were considered: 
1) Static attacks try to request hidden (or non-existent) 
resources. These requests include obsolete files, session 
id in URL rewrite, configuration files, default files, etc. 

2) Dynamic attacks modify valid request arguments: SQL 
injection, CRLF injection, cross-site scripting, buffer 
overflows, etc. 

3) Unintentional illegal requests. These requests should 

also be rejected even though they do not have malicious 
intention. 


The attacks were generated with the help of the tools Paros 
[10] and W3AF[11]. 


D. Training Phase 


During the training phase, the system learns the web ap- 
plication normal behavior. The aim is to obtain the XML file 
from the normal requests collected. 

Only normal requests are used to train the system. In our 
case, the requests used to train the system are part of those 
stored in the NormalDB database. 

In the construction of the XML file, different aspects must 
be taken into account: 


+. The methods and the resources found in the normal 
requests are included directly in the XML file as allowed 
elements. 

+. Header names are directly included in the XML file. Their 
values are characterized by extracting the corresponding 
length and character structure (Markov chain) properties 
from the requests. 

+. Likewise, argument names included in the XML and their 
values are characterized by the corresponding properties 
(length and character structure) from the requests. 


E. Test Phase 


During the test phase, the proxy analyzes both normal and 
anomalous requests. The proxy receives part of the requests 
from the NormalDB database (those not used for the training) 
and also the requests from the AnomalousDB. 

The performance of the detector is often measured using 
Receiver Operating Characteristic (ROC) curves [12]. A ROC 
curve plots the attack detection rate (true positives, TP) against 
the false alarm rate (false positives, FP). 


, TP 
DetectionRate = =——— 
TP+FN 
FP 
FalseAlarmRate = == 
FP+TN 


During the test phase, different parameters can be modified 
to tune the detection models: 


+. The parameter p corresponds to the percentile used in the 
length model. 

+. The parameter e is used to smooth the Markov model and 
it is a value assigned to transition probabilities which, in 
the trained model, are O or lower than a threshold. Lower 
values of e makes the system more sensible to deviations 
with respect to the normal behavior. 

+. The parameter T is used to decide whether a 
header/argument value is normal or anomalous. If the 
value of the parameter is very low, the detection is more 
prone to false positives. If the parameter is very high, 
it is not possible to detect attcks with a low level of 
abnomality. 


F. Results 


Several series of experiments have been carried out to test 
the performance of the system, using different combinations 
of the parameters to tune the detection models. For each 
series of experiments, the proxy was fed with 10000 normal 
requests during the training phase. Besides, ten different values 
of T were used to obtain the points in each ROC curve: 
T= [30,40,...,100,200,3007. 

The first series of experiments aims to compare the effect of 
e in the Markov detection model. Figure 3 shows the ROC of 
these experiments, using four different values of e. The results 
show that lower values of e, specifically when e = 1071, give 
better performance. 

The second series of experiments aims to compare the 
effect of p in the lengh detection model. Figure 4 shows the 
ROC of these experiments, using three different percentiles 
p=0.90,p =0.95,p =0.99. The higher value makes the 
model more permisive. 

In general, the experiments show a very high detection rate. 
The majority of the attacks given in the input during the test 
were rejected. As a consecuence of the positive approach, all 
inputs requesting resources that were not placed in the XML 
were rejected. This feature is as determinant as the detection 
models. 

On the other hand, about the 20% of the normal requests 
were tagged as intrusive. While this false alarm rate is too high 
for real applications, it is reasonably in the experimental scope. 
The false alarm rate can be reduced by increasing the number 
of training requests, tuning the detection model parameters and 
incorporating new detection models to the system. 

It is important to notice that when the XML file closely 
characterizes the web application normal behavior, the differ- 
ent kinds of attacks can be successfully detected and just a 
few false alarms are raised. 


IV. LIMITATIONS AND FUTURE WORK 


As shown in the previous section, when the XML file is 
configured correctly, the system succeeds in detecting any kind 
of web attack. Thus, the main issue is how to automatically 
configure the XML description file. In our approach, the XML 
file is built from a set of allowed requests in the target web 
application. However, obtaining only normal traffic might not 
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Fig. 3. Comparison of the 4 ROC curves of the WAF for e = 10—15, 
e = 10-10, e = 10-8, e = 10-4. In every curve the parameter T is tuned 
taking values from 30 to 300. 10000 training requests were used and the 
percentile is set to 0.99 


percentile=0.90 —H— 
percentile=0.95 -"0---- 
percentile=0.99 "ud 


DetectionRate 


0 0.2 0.4 0.6 0.8 1 
FalseAlarmRBate 


Fig. 4. Comparison of the 3 ROC curves of the WAF for percentile = 0.90, 
percentile =0.95, percentile =0.99. In every curve the parameter T is tuned 
taking values from 30 to 300. 10000 training requests were used and e is set 
to 10715 


be an easy task, as was discussed in Sec. III-B. Therefore, the 
main limitation consists in correctly implementing the training 
phase for any web application. 


Other limitations of the system arise when protecting com- 
plex web applications. For instance, web sites that create 
and remove pages dynamically, generate new URLs to access 
resources, or allow users for updating contents, might difficult 
the XML file configuration. 


As future work, we have several ideas to try to solve the 
limitations mentioned before and to improve the system. URL 
patterns can be used in describing sites with dynamic resources 
in order to solve the protection of complex web applications. 
We are also working on experiments using real traffic. As 
real traffic may contain attacks, a filtering phase could be 
applied to purify the real traffic before the training phase, thus 
obtaining a more precise description of the web application 
normal behavior. In addition, more detection models can be 
included in order to compare their results and conclude which 
one is more efficient. 


V. CONCLUSIONS 


We presented an efficient web attack detection system or 
Web Application Firewall (WAF). As the system is based on 
the anomaly-based methodology it proved to be able to protect 
web applications from both known and unknown attacks. The 
system analyzes input requests and decides whether they are 
anomalous or not. For the decision, the WAF relies on an XML 
file which specifies web application normal behavior. 

The main challenge is how to create an accurate XML 
file in a fully automated manner for any web application. In 
our system, we show that inasmuch great amounts of normal 
traffic are available for the target application, this automatic 
configuration is possible. The XML file contains a list of the 
normal HTTP methods, headers, resources and arguments of 
the web application. The normal values of the headers and the 
arguments are characterized using Markov chains and length 
intervals. 

Our system has been configured to protect a specific real 
web application. The experiments for the WAF protecting real 
web applications show that as long as the XML file correctly 
defines normality for a given target application, very satisfying 
results are obtained. 
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Abstract— Cognitive radio networks sense spectrum occupancy 
and manage themselves to operate in unused bands without 
disturbing licensed users. Spectrum sensing is more accurate 
if jointly performed by several reliable nodes. Even though 
cooperative sensing is an active area of research, the secure 
authentication of local sensing reports remains unsolved, thus 
empowering false results. This paper presents a distributed 
protocol based on digital signatures and hash functions, and an 
analysis of its security features. The system allows determining 
a final sensing decision from multiple sources in a quick and 
secure way. 

Index Terms —authentication, cognitive radio, cooperative sens- 
ing, cryptography 


TI. INTRODUCTION 


Spectrum is an essential resource for the provision of mobile 
services. In order to control and delimit its use, governmen- 
tal agencies set up regulatory policies. Unfortunately, such 
policies have led to a deficiency of spectrum as only few 
frequency bands are left unlicensed, and these are used for 
the majority of new emerging wireless applications. Besides, 
studies conducted by the Spectrum Policy Task Force show 
that most of the licensed spectrum is largely under-utilized 
[1]. 

One promising way to alleviate the spectrum shortage 
problem is adopting a spectrum sharing paradigm in which 
frequency bands are used opportunistically. In this scheme, 
those who own the license to use the spectrum are referred 
to as primary users, and those who access the spectrum 
opportunistically are referred to as secondary users. Secondary 
users must not interfere with primary ones, who always have 
usage priority. 

The enabling technology for opportunistic sharing is cogni- 
tive radio (CR) [2]. A CR is a system that senses its electro- 
magnetic environment and can dynamically and autonomously 
adjust its operating parameters to access the spectrum. CR 
terminals form self-organizing networks capable to detect 
vacant spectrum bands that can be used without harmful 
interference with primary users. Once a vacant band is found, 
secondary users coordinate themselves in order to share the 
available spectrum. 

Performing reliable spectrum sensing is a difficult task. 
Wireless channels can suffer fading, thus provoking the hidden 
node problem in which a secondary user fails to detect a 
primary transmitter. The most important challenge for a CR 
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is to identify the presence of primary users, and, for this 
reason, secondary users must be significantly more sensitive 
in detecting primary transmissions than primary receivers. 

In order to reduce the sensitivity requirements of individual 
CRs, recent studies propose performing distributed spectrum 
sensing (DSS)[3]. In DSS, multiple secondary users cooperate 
and share their local sensing results, which are then merged 
together to reach a final decision. Although the use of cooper- 
ation in spectrum sensing has been extensively studied, some 
security issues still remain unsolved. 

The problem of current spectrum sensing protocols is 
that they do not provide any mechanism to authenticate the 
observations exchanged by secondary users. This problem 
is present even in those protocols that intend to deal with 
malicious users. Secure spectrum sensing protocols assume 
that sensing reports from secondary users can be effectively 
authenticated. As a result, malicious users can be detected - 
their reports repeatedly differ from the final decision- and their 
contributions discarded. However, a mechanism to authenticate 
the observations sent by secondary users is still missing. 

This paper presents a protocol that enables the secure 
authentication of sensing information. The protocol is mainly 
based on the use of hash functions, so that authentication 
is carried out as quickly as possible. Performing spectrum 
sensing without significant delay is essential because a lengthy 
sensing process reduces the time left for transmission. Further- 
more, a lengthy sensing process will certainly consume more 
energy at the CR. Thus, the combination of the proposed pro- 
tocol with the existing data fusion schemes allows distributed 
spectrum sensing to be conducted effectively. 


II. BACKGROUND 


Cooperative sensing is based on merging the local obser- 
vations of multiple secondary users. Traditionally, there are 
two techniques which are used for local spectrum sensing: 
energy detection or cyclostationary feature detection. Energy 
detection is based on integrating the energy received over an 
observation interval. This method is optimal when secondary 
users do not have sufficient information about the primary user 
signal. On the other hand, cyclostationary feature detection 
takes advantage of the fact that signals used in wireless 
communications are cyclostationary. Thus, their features can 
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be detected using a spectral correlation function. However this 
method requires longer observation times. 

Since local spectrum sensing results are subject to multi- 
path and/or shadowing fading, the cooperation among CRs is 
fundamental to achieve a reliable decision. This cooperation 
can be implemented in a centralized or distributed manner. In 
the centralized method, the base station or fusion center (FC) 
gathers all the information from secondary users and executes 
the data fusion to reach the final decision. On the other hand, 
distributed solutions require all secondary users to exchange 
their local observations, so that the data fusion operation is 
carried out independently on each secondary device. 

Several data fusion schemes have been proposed to merge 
the sensing data observed by each secondary user. These 
schemes are based on exchanging of more or less infor- 
mation depending on whether devices perform hard or soft 
cooperation. When hard cooperation is employed, radios only 
exchange their final decision: primary user detected or not 
detected. On the other hand, soft cooperation means that radios 
exchange their local test statistics with each other. Among the 
proposed methods, the most typical one is based on applying 
the “k out of N” rule. This rule determines that the channel is 
occupied if at least k of the N secondary users have detected 
the primary signal. As avoiding interference with primary 
users is a top priority, the most common value of k is 1. 

Other methods proposed for merging the sensing data are 
based on modeling the fusion process as a probabilistic prob- 
lem. Zarrin and Lim [4] compute the probability of detection 
by performing the likelihood ratio test (LRT), which is based 
on the Neyman-Pearson theorem and is used for optimal 
decision making. Wang et al. [5] apply another probabilistic 
method where secondary users are classified according to 
their SNR level and those with higher levels are given more 
influence on the final decision. Alternatively, Chen et al. [6] 
propose the use of a Sequential Probability Ratio Test (SPRT). 
SPRT is a data fusion scheme that supports a variable number 
of local spectrum sensing results. The protocol assumes that 
the number of sensing results can be increased and adjusted 
as necessary, so it guarantees both a bounded false alarm 
probability and a bounded miss detection probability. The 
authors also suggest the use of a reputation-based scheme to 
increase the robustness of the data fusion process. 

The introduction of reputation mechanisms in the sensing 
process has also been considered in some studies. In [7], a 
two-step protocol for the detection of malicious users that 
report false sensing data is proposed. In the first step, an outlier 
detection method is applied to pre-filter those sensing results 
that are too distant from the rest of the data. In the second 
step, each user is associated with a trust factor that is based 
on the past and present sensing data sent by the user. Thus, the 
trust factor lends more or less weight to a decision depending 
on the reliability of the corresponding user. 

Another important issue to take into account when perform- 
ing spectrum sensing is preventing primary user emulation 
attacks. These attacks allow a malicious secondary user to 
gain priority over others by emulating the signal of a primary 


user. Solutions to this problem are based on checking whether 
the estimated location of the transmitter and its signal charac- 
teristics match the ones of the licensed primary user [8]. 

As we have shown, several studies have approached the 
problem of providing security and reliability to the spectrum 
sensing process. However, no proposal has been presented so 
far to authenticate the sensing data provided by a secondary 
user. Without such authentication, the proposals based on 
associating a reputation or a probability of detection to each 
user become useless. The combination of existing protocols 
with a secure authentication method can undoubtedly improve 
the performance of spectrum sensing protocols in the presence 
of faulty radios or malicious users. 


TII. PROTOCOL 


This section presents our protocol for the secure authenti- 
cation of users” sensing reports. The protocol prevents users 
from illegitimately claiming false identities and from injecting 
fake sensing data. Thus, the protocol aims at withstanding the 
following attacks: 


+. Altering the final sensing decision. A user could incre- 
ment her weight in the data fusion process by forging 
several identities and making a contribution for each of 
them. With enough forged identities, a user might be able 
to completely alter the aggregate reading. 

+. Deceiving the reputation system. By using a different 
identity each time, a user might report false sensing data 
repeatedly and avoid earning a bad reputation. 

+. Obtaining resources unfairly. A user could use many 
identities to obtain more than her fair share of resources 
(e.g. bandwidth). 


The proposed protocol assumes that the cooperation among 
CR's is implemented in a centralized manner, which is the 
most frequently used configuration in the spectrum sensing 
protocols presented to date. We also assume that the secondary 
users and the fusion center can use a common control channel. 

To perform distributed sensing securely, the cooperative 
system should identify the users that participate in the sensing 
process, authenticate their claims, and weigh up their con- 
tribution to the final decision based on their reputation or 
probability of successful detection. Our protocol focuses on 
the mechanisms required to identify the users and authenticate 
their sensing results. The final part of the distributed sensing 
process (1.e. weighing up and merging the contributions) can 
be implemented using any of the mechanisms that we have 
mentioned in the previous section. The selection of which data 
fusion technique to use is out of the scope of this paper. 

One of the key goals of the protocol design has been to 
develop a quick authentication process. We take a public 
key infrastructure (PKI) approach to identify the peers of the 
network through digital signatures. Even though this process 
1s costly, it has to be executed only once, in the setup phase. 
Then, we make use of efficient Hash Message Authentication 
Code (HMAC) functions to protect users” sensing reports from 
forgery and manipulation. 
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HMAC functions provide message authenticity and integrity 
by calculating a hash of two inputs: the target message and a 
secret key. In our protocol, we use hash chains to produce one 
time secret keys. Hash Chains, first proposed by Lamport [9], 
are versatile low-cost constructions that are used extensively 
in various cryptographic systems. 

The proposed protocol is divided in two phases. The first 
phase is the identification of users, and the second one is the 
collection of sensing results. In the following sections, we will 
describe each one of these phases in detail. 


A. Phase 1: user authentication 


In the first phase, the user contacts the fusion center (which 
can be, for instance, the base station) and asks permission 
to join the cognitive radio network. Besides, she commits 
to a hash chain by attaching the top value of the chain in 
the request. This process requires mutual authentication using 
digital signatures. At this point, the fusion center decides 
whether or not to accept the user into the network. The 
following are the detailed steps carried out during this phase. 


1) User U chooses a random number wy and prepares a 
hash chain of length N, where N is chosen by the fusion 
center and it is shared by all network members. 

Hash chains are composed of a sequence of values that 
can only be computed in one-way. A hash chain of 
length N is constructed by applying a one-way hash 
function H(.) recursively to an initial seed value wy: 
wy1 = Hlwn), Wy-2 = Hlwny-1), +*-, Wy = 
HN (wn). In general, 10, = H(w¡+1) = HN =*(wy). 
U sends the top value of her chain (10) to the fusion 
center FC in a digitally signed message. The signature 
is computed using U”s private key puky. She also 
includes information about her identity /dy (i.e. the 
unique identifier of her public key certificate). 


2 


— 


JoinReq = [wo, Idy, Signpury (wo, Idy)+ 


3) FC verifies the signature received from U using U”s 
public key pbky. If the signature is correct, FC decides 
whether or not to accept U into the network. This 
decision will be based, for example, on the reputation 
earned by U in previous processes. The implementation 
of these mechanisms is out of the scope of this paper. 


B. Phase 2: collection of local sensing results 


In the second phase, the fusion center requests each user to 
sense a certain set of frequency bands. Users conduct spectrum 
sensing using a mechanism based on the energy perceived, 
cyclostationary statistics, or any other method. Then, they sign 
their own local sensing results with a HMAC function and send 
the sensing data and its signature to the fusion center. The keys 
used to compute the HMACs are taken from the hash chain, 
so that the fusion center can verify the identity of the sender. 
The following are the detailed steps carried out in this phase. 


1) At time £t, FC broadcasts a signed message with a task 
list (TaskList) that contains the list of channels each 
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2) 


3 


= 


4) 


5) 


user has to sense. 
SensingReq, = TaskList;, Signpvr y (TaskList,, t) 


where 


TaskList; = [((Ido, Channel Listo, i0):-* 
(Ids, Channel Listg,is)] 


In the above expression, S is the total number of 
secondary users, and 2; is the hash chain index that 
points to the value the user ¡ must use in the following 
step. 

Each user U verifies the signature of the sensing re- 
quest and, if correct, senses the channels listed in 
Channel Listy. After completing the sensing process, 
each user sends the results SensingRes to FC. These 
results can be binary decisions or long test statistics, 
depending on whether hard or soft cooperation is in use. 
To allow the authentication of the sensing results, these 
are sent as follows: 


SignRes; = SensingRes;, HMAC(SensingRes;,w;) 


The key used to construct the HMAC is 10,, where 1 is 
the index received from FC in SensingReq:. 

FC waits for the reply of all secondary users and at time 
t' (with t! =t+ At), it generates a new TaskList;. 
This new task list can contain empty Channel Lists if 
there are not more channels to sense. 


SensingReqy = TaskList¿, SigNpvk y (TaskList;r) 


where 


TaskListy = [(Ido, Channel Listo, Li + 1)o):** 
(Ids, Channel Lists, Li + 1) 5)] 


Each user U verifies the signature of the sensing re- 
quest and creates a reply that depends on whether 
the corresponding ChannelList is empty or not. If 
ChannelList is not empty, then the results are con- 
structed as follows: 


SignResy = SensingkResy, 
HMAC(SensingResy,w¡+1), wi 


Otherwise, they just contain the key needed to verify the 
previous HMAC sent to FC in SignkRes;. 


SignResy = w; 


As can be seen, the response always includes the key 
w, used to create the previous signed results sent in 
SignRes;. 

FC waits for the reply of all secondary users and verifies 
the HMACs from the Sign Req. If more channels need 
to be sensed or more HMACs need to be verified, a new 
request is generated. Otherwise, FC starts the fusion of 
the sensing results. 


IV. DISCUSSION 


The presented protocol provides a way to authenticate 
sensing reports with a minimum overhead. Each user has 
to generate a digital signature when she accesses the fusion 
center for the first time. Afterwards, she only has to validate 
digital signatures (which is very efficient [10]), and compute 
HMAC using a costless hash function. The HMAC keys 
can be generated and checked with efficient mechanisms for 
fast chain traversal [11], [12] and for economic setup and 
verification [13], [14]: a one-way chain with N elements only 
requires log(N) storage and log(N) computation to access an 
element. 

From the security point of view, the proposed system is 
robust against Sybil attacks, in which a user illegitimately 
claims multiple identities, and the injection of false sensing 
reports. Sybil attacks are prevented using certificates generated 
by a trusted central authority. If a user does not own a valid 
certificate, she is not authorized in the CR network and can 
not send sensing reports to the fusion center. On the other 
hand, the injection of false sensing reports is avoided using 
verifiable HMAC signed reports. 

Reporting a verifiable sensing result involves two user 
transmissions. First, the user sends the sensing data and its 
corresponding HMAC. Then, she reveals the HMAC key, 
which is an element of a hash chain. The fusion center verifies 
the integrity of the sensing message and the authenticity of the 
key. 

Sensing reports are protected against modification attacks 
since they are signed with an HMAC. Keys used to compute 
the HMAC are taken from the secret hash chain w of each 
user. Therefore, only the user who created the hash chain can 
compute the corresponding HMAC. 

Reply attacks are avoided because each HMAC key is used 
only once. The fusion center indicates in the sensing request 
which element 3 it has to be used. Chain elements are asked in 
ascending order (Wwyg, 1, .. Wy) SO knowing a user's previous 
key gives no information about the present one. Moreover, the 
sensing request is signed so that an attacker can not modify 
the requested hash index. 

Additionally, as the sensing requests and replies are syn- 
chronized by 2, it is not effective to block the user's reports 
in order to steal her keys to later generate fake reports. 


V. CONCLUSION 


In this paper, we have identified the security vulnerabilities 
of a cooperative sensing process and its prejudicial effects 
in CR networks. We have proposed a secure protocol for 
centralized based systems that uses digital signatures and hash 
functions. 


The protocol enables the fusion center to verify the identity 
of network members and to ensure the received sensing infor- 
mation is really originated from the claimed source. One of the 
main features of the proposal is the fact that is computationally 
efficient and introduces a small bandwidth overhead. As part 
of our future research, we plan to integrate reputation measures 
into the scheme. 
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Resumen—La radio cognitiva es una tecnología inalámbrica 
propuesta para usar eficientemente los recursos del espectro 
radioeléctrico permitiendo así reducir la carga existente en las 
bandas de frecuencia de uso libre. Las redes de radio cognitiva 
son capaces de escanear el espectro y adaptar sus parámetros 
para operar en las bandas no ocupadas. Para evitar interferir 
con usuarios con licencia que operan en un determinado canal, 
la sensibilidad de las redes tiene que ser muy alta. Ello se 
consigue con métodos de detección cooperativos. Los métodos de 
detección cooperativa actuales tienen una carencia de robustez 
ya sea frente a ataques puntuales o continuos. En este artículo 
presentamos un método de fusión por grupos que tiene presente el 
comportamiento de los usuarios a corto y largo plazo. Al realizar 
la fusión de los datos, el método se basa en dar mayor peso a 
los grupos de usuarios con mayor unanimidad en sus decisiones. 
Los resultados de las simulaciones prueban que en presencia de 
atacantes el método de fusión por grupos propuesto consigue una 
detección superior a otros métodos, cumpliendo los requisitos de 
sensibilidad mínimos de las redes de radio cognitiva incluso con 
un 12% de usuarios reiteradamente maliciosos o un 10 % de 
atacantes puntuales. 


I. INTRODUCCIÓN 


Los numerosos servicios de redes inalámbricas disponibles 
hoy en día han producido un aumento en la demanda de 
espectro radioeléctrico. Los recursos de espectro son limitados 
y están controlados por agencias gubernamentales que otorgan 
licencias para su uso. Sólo una pequeña parte del espectro 
se puede usar de forma libre, y esta banda está cada día 
más sobrecargada. Por contra, el uso de otras frecuencias no 
supera el 15%. Así pues, como ha manifestado la Federal 
Communicacitions Commission (FCC) [3] el reparto y uso 
actual del espectro es ineficiente. 

Las redes de radio cognitiva están surgiendo como una 
tecnología clave para llevar a cabo una gestión más óptima 
del ancho de banda disponible [1]. Se caracterizan por tener 
la capacidad de escuchar el uso que se hace del espectro y 
adaptar consecuentemente sus parámetros de comunicación 
para aprovechar los huecos libres que existen en muchas de las 
frecuencias licenciadas. Ello permite a los usuarios compartir 
el espectro de forma oportunista y evitar colisiones tanto 
con los servicios licenciados -televisión, telefonía móvil, etc.-, 
como con otros usuarios sin licencia que quieren aprovechar 
el ancho de banda libre de la red. Las entidades y usuarios que 
ofrecen o consumen servicios con licencia son denominados 
usuarios primarios dado que tienen prioridad en el uso de 
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la red, mientras que los usuarios sin licencia se conocen 
como usuarios secundarios. Actualmente el estándar de radio 
cognitiva que se está desarrollando es el IEEE 802.22 que 
opera sobre las bandas de frecuencia de los servicios de 
televisión y está dirigido a formar redes de área regional. 

El requisito principal de los sistemas de radio cognitiva es 
evitar interferir a los usuarios primarios. Sin embargo, dicha 
tarea es complicada debido a la propia naturaleza del medio 
inalámbrico. Las señales pueden sufrir desvanecimientos pro- 
fundos debido al efecto multicamino o porque han atravesado 
un medio con alta atenuación. Este efecto puede ocasionar 
el problema del terminal oculto en el que un nodo secundario 
falla en la detección de una señal primaria. Para evitar errores, 
la sensibilidad de las radios cognitivas debe ser mucho mayor 
que la de los receptores primarios. Desarrollar sensores que 
individualmente garanticen los requisitos de sensibilidad que 
exige una radio cognitiva es muy costoso. Es por ello que 
las soluciones comúnmente adoptadas pasan por utilizar otra 
estrategia: la detección cooperativa [4]. 

Las técnicas de detección cooperativas combinan los resul- 
tados de la monitorización espectral que han realizado varios 
usuarios secundarios individualmente y obtienen una decisión 
final acerca de la presencia de un usuario primario en la banda 
de operación. Dado que el efecto multicamino y el ensombrec- 
¡miento son factores locales que degradan la detección de sólo 
algunos nodos de la red, los esquemas detección cooperativa 
permiten mitigar dichos efectos, obteniendo así un aumento 
en la probabilidad de detección del usuario primario. Sin 
embargo, este paradigma conlleva unos riesgos de seguridad, 
ya que los nodos pueden reportar información falsa que altere 
la decisión del estado final del espectro. 

Aunque en la literatura hay múltiples propuestas sobre 
métodos de detección cooperativos, pocos de ellos consideran 
la presencia de usuarios maliciosos en la red que envíen datos 
erróneos a propósito. Los que lo hacen, requieren general- 
mente información a priori sobre las condiciones del entorno, 
ya sea el perfil de los nodos del sistema, las características de 
la señal y el ruido, la frecuencia de ocupación de los canales, 
etc. 

En este artículo, se propone un nuevo método de fusión 
de detección cooperativa para radios cognitivas que no asume 
el conocimiento previo del contexto y que es robusto frente 
a ataques maliciosos. El algoritmo propuesto utiliza las deci- 
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siones locales de los múltiples nodos y los divide en cuatro 
grupos según su factor de aciertos en pasadas detecciones, con- 
siderando tanto los resultados obtenidos a corto y largo plazo. 
Los grupos toman una decisión basándose en la detección de 
la mayoría de sus miembros. Finalmente, las decisiones de los 
grupos son fusionadas teniendo en cuenta la reputación global 
del grupo y su unanimidad en la decisión. 

El resto del artículo está organizado de la siguiente forma. 
En la sección II, se describen aspectos generales sobre la 
detección cooperativa de señales primarias y sobre métodos 
básicos de fusión cooperativa. El método de fusión de datos 
por grupos propuesto se explica en la sección III. En la 
sección IV, los resultados de las simulaciones verifican el 
funcionamiento del método propuesto comparado con métodos 
básicos. Finalmente, la sección V presenta las conclusiones del 
artículo. 


II. TÉCNICAS DE DETECCIÓN COOPERATIVAS 


En esta sección presentaremos, en primer lugar, aspectos 
generales sobre las técnicas de detección cooperativas y, en 
segundo lugar, describiremos los métodos de fusión coopera- 
tivos básicos más usados. 

Una red de radio cognitiva está formada por un grupo de 
usuarios secundarios que escanean periódicamente su entorno 
radioeléctrico para detectar la presencia de usuarios primar- 
los. Los usuarios secundarios se encuentran bajo diferentes 
condiciones de atenuación. 

La mayoría de técnicas de detección cooperativas utilizan 
un centro de fusión que recoge los datos enviados por los 
nodos secundarios acerca de los resultados de su detección 
local. El centro de fusión ejecuta un determinado método de 
fusión sobre los datos para obtener la decisión final. 

Los métodos de fusión utilizados por el centro de fusión se 
pueden clasificar en dos tipos: métodos de fusión de datos 
multi-nivel (soft-combining) y métodos de fusión de datos 
binarios (hard-combining). Los primeros fusionan información 
sobre la medida realizada por cada nodo. La fusión propor- 
ciona datos muy ajustados pero el volumen de datos que se 
requiere que los nodos envíen al centro de fusión es muy 
elevado. Por otro lado, los métodos de fusión de datos binarios 
realizan la fusión de las decisiones locales sobre si existe o no 
usuario primario. Cada una de las decisiones locales se envían 
al centro de fusión en forma binaria. La principal ventaja de 
estos métodos es que reducen la cantidad de datos enviados. 

Los métodos detallados en este artículo emplean datos bi- 
narios para realizar la fusión. Antes de presentar los diferentes 
métodos propuestos para implementar la detección cooperati- 
va, vamos a describir dos parámetros que son importantes a la 
hora de evaluar el funcionamiento de una determinada técnica 
de fusión de datos. 

El primer parámetro es la probabilidad de detección y se 
define como la probabilidad de acierto en la detección de 
un usuario primario. Esta probabilidad indica cómo de bueno 
es el método evitando las interferencias al usuario primario. 
Cuando la probabilidad de detección es alta, conseguimos un 
nivel elevado de protección de la señal primaria. El segundo 


parámetro es la probabilidad de falsa alarma y representa 
la probabilidad de detectar un usuario primario cuando en 
realidad éste no existe. Cuanto menor sea la probabilidad de 
falsa alarma, el uso de los canales libres será más eficiente. 


Il-A. Métodos de fusión de datos binarios 


En este apartado introducimos las principales técnicas de 
fusión de datos binarios existentes para detección cooperativa. 

Las reglas OR, AND o Mayoría son los métodos de fusión 
de datos más básicos y se adaptan a cualquier situación [8]. 
Estas técnicas deciden sobre la ocupación del canal sumando 
cada una de las decisiones de los NV nodos del sistema (u;) y 
comparando el resultado con un umbral. En función del valor 
del umbral de decisión, estaremos hablando de las reglas AND, 
OR o Mayoría. 

La regla OR declara que el usuario primario está presente si 
al menos uno de los nodos ha detectado al usuario primario: 


N 

Si y, uz1 => señal primaria presente 
¿=1 
Otro; => señal primaria absente 


En la regla AND el umbral de decisión para declarar que 
existe usuario primario es el total de nodos N: 


N 

Si $ u=N => señal primaria presente 
¿=1 
Otro; => señal primaria absente 


En la regla de fusión por Mayoría se declara el canal 
ocupado cuando como mínimo la mitad de los nodos hayan 
detectado al usuario primario: 


N 


1 
. ui >2xN = señal primaria presente 
Si 2 50) Pp Pp 
yA 
Otro; => señal primaria absente 


Otra posibilidad para fusionar los datos del análisis del 
espectro se basa en realizar el Likelihood Ratio Test (LRT) y 
de ese modo obtener una decisión final Óptima. Al modelar el 
proceso de fusión como un problema probabilístico es nece- 
sario disponer de información adicional, a parte de conocer 
las decisiones locales de los nodos. En particular, se deberán 
conocer: la probabilidad a priori de u, cuando la decisión final 
es que no hay usuario primario (P(u;|Ho)) y la probabilidad 
a priori de u¿ cuando se decide que existe usuario primario 
(P(u;|H)). El cálculo del LRT se realiza según la siguiente 
expresión: 


donde HH, representa la hipótesis de que el canal está libre y 
H de que está ocupado. El resultado del LRT se compara 
con un determinado umbral A para obtener la decisión final 
(Hy o H;). Este método deberá ser utilizado en entornos más 


372 


estáticos y donde se conozcan determinados parámetros del 
sistema. 

La detección colaborativa permite obtener un análisis de 
las bandas frecuenciales libres más preciso que una única 
detección local. Sin embargo, el buen funcionamiento de estos 
métodos puede estar afectado por los siguientes problemas. 

En primer lugar, las señales que reciben los nodos secunda- 
rios pueden llegar severamente atenuadas o simplemente puede 
ocurrir que el terminal secundario no funcione correctamente y 
realice un análisis del espectro erróneo. Estas causas provocan 
equivocaciones en la decisión del nodo al detectar la señal 
primaria. 

En segundo lugar, puede ocurrir que el sistema contenga 
usuarios maliciosos. Este tipo de nodos envían información 
falsa al centro de fusión alterando los resultados de sus 
medidas del espectro para alterar la decisión final. Este tipo 
de ataques conduce a equivocaciones cuando se realiza el 
algoritmo de fusión de datos. Algunos de los efectos que 
esto puede producir son el error de falsa alarma o fallo de 
detección. El caso de falsa alarma reduce el rendimiento del 
sistema. Sin embargo, el caso de fallo de detección tiene 
consecuencias más serias porque puede provocar interferencias 
a los usuarios primarios. 

Como resultado de estos problemas recientemente se han 
investigado nuevos métodos de fusión que implementan con- 
tramedidas para atenuar los efectos de los ataques de falsi- 
ficación de datos o los efectos de equipos defectuosos que 
inconscientemente envían resultados incorrectos. 

Lim et al. presentan un método de fusión de datos binarios 
que utiliza vectores de confianza y reputaciones [5]. El vector 
de confianza es un índice asignado por el propio nodo según 
la confianza que él tiene de la precisión del resultado de sus 
medidas. La reputación representa la precisión de un nodo en 
su historial de medidas respecto a las decisiones finales. 

En primer lugar, un nodo escanea el espectro, toma una 
decisión sobre la ocupación del canal, y determina un valor 
de confianza. Luego, el nodo modifica el valor del vector de 
confianza con un signo positivo si el nodo decidió que el canal 
estaba ocupado y con signo negativo en el caso contrario. 

A continuación, los nodos envían al centro de fusión sus 
decisiones locales junto con el nuevo valor de confianza. 
El centro de fusión agrupa todos los resultados utilizando 
la regla de fusión por mayoría ponderada con pesos. Los 
pesos representan la reputación de cada nodo, de manera 
que se asignan pesos mayores a los nodos más fiables. Por 
consecuencia, las decisiones de estos nodos contribuyen en 
mayor medida a la decisión final. 

La decisión final u se obtiene según la siguiente expresión 


a Í l, si »),cjw, >0 
O st Yet 0 
donde e; es el vector de confianza para un usuario 2 y w; el 
factor de reputación. 
Existen otros métodos de fusión binaria y cooperativos que 
han sido propuestos con el objetivo de reducir el efecto de 
nodos maliciosos ([6], [2], [9]) pero su ámbito de aplicación 


no es tan genérico por requerir el conocimiento de cierta 
información de entorno. 


III. MÉTODO DE FUSIÓN EN GRUPOS PROPUESTO 


Los métodos de fusión de datos binarios propuestos hasta 
ahora han sido diseñados para entornos inalámbricos muy 
estáticos y en los que la presencia de atacantes es limitada. 
En concreto, sólo se asume la presencia de atacantes de 
tipo SIEMPRE-SI (siempre dicen que la banda del espectro 
a analizar está ocupada) y de tipo SIEMPRE-NO (siempre 
dicen que la banda del espectro a analizar está libre). Sin 
embargo, nodos que normalmente prestan un buen servicio 
a la comunidad con una detección fiable de los canales 
espectrales, pueden sesgar su visión del sistema en el momento 
en el que son ellos mismos los que necesitan un canal de 
comunicaciones. Un nodo egoísta puede manipular el sistema 
y decir que un canal está ocupado cuando en realidad no es 
así, por el simple hecho de poder ocupar él este canal sin 
tener que compartirlo con los demás nodos de la comunidad. 
También puede darse el caso que un nodo malicioso informe 
que un canal está libre cuando está ocupado, por el simple 
hecho de interferir y provocar una denegación de servicio a 
los nodos primarios. 

En este artículo, proponemos un método de fusión de datos 
que tiene en cuenta el comportamiento y la reputación de los 
usuarios a largo plazo, pero que también está preparado para 
soportar los cambios bruscos del entorno y por consecuencia, 
de las decisiones incoherentes de los nodos. Para ello clasifi- 
camos los nodos en grupos según su comportamiento pasado. 
Los grupos toman una decisión basándose en la detección de 
la mayoría de sus miembros. Finalmente, las decisiones de 
los grupos son fusionadas dando mayor peso a los grupos de 
usuarios que más han acertado en pasadas detecciones y que 
presentan mayor unanimidad de voto en la decisión actual. 


IIFA. Clasificación de los nodos 


Definimos la reputación de un nodo como un valor que mide 
los aciertos a largo término de sus decisiones de detección, esto 
es, cuando la decisión local del nodo y la global del sistema 
coinciden. La reputación r, € [0, 1] de un nodo ¿ es: 


Da Qi 

N; 
donde a; es el número de aciertos del nodo ¿ sobre un total 
de N;, detecciones. 

Por otro lado, definimos la estabilidad de un nodo como 
un valor que ilustra los cambios contextuales o de conducta 
de un nodo en un corto instante de tiempo. Calculamos la 
estabilidad e; a partir de los aciertos de detección de un nodo 
1 en un corto espacio de tiempo correspondiente a 4 iteraciones 


de detección: pa 
Dion -3 0 (h) 
E 4 


donde a;(k) es una función que retorna O o 1 cuando el nodo 
1 en el instante de tiempo k falla o acierta la detección del 
nodo primario, respectivamente. 


T¡= 


e; 
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A partir de la reputación r, y la estabilidad e;, un nodo 
obtiene un factor de incidencia ww, € [0,1] en la decisión: 


Wi = Yi" €; 
IIFB. Algoritmo de decisión 


Los nodos hacen la detección del espectro y envían al centro 
de fusión la decisión local d, = (—1,1) para indicar que la 
banda está libre (—1) o ocupada (1). El algoritmo de fusión 
propuesto está basado en la regla de fusión por mayoría, pero 
en lugar de tratar por igual las decisiones de todos los nodos, 
el sistema las pondera según el factor de incidencia de los 
nodos y el grado de unanimidad de la decisión. 

En primer lugar el centro de fusión ordena los nodos que 
participan en la detección cooperativa de forma ascendente 
según el valor de su factor de incidencia. Luego clasifica los 
nodos en cuatro cuartiles (G,, Ga, G3 y G4). Los valores de 
corte de los cuartiles (A12, A23, y A34) vienen determinados 
por el factor de incidencia de los nodos que ocupan las 
posiciones al 25%, 50% y 75% de la longitud de la lista, 
respectivamente. Así, los nodos son clasificados en grupos 
según el valor de su factor de incidencia de la siguiente forma: 


0< w < Aza; > € Ga 
Si Aza <w¡< Aa; => u € G3 
A23 <w < Aa; => u € Ga 
Aja <w¡<l; > u€G; 


El centro de fusión agrega los datos reportados por los 
diferentes nodos de la siguiente manera: 


G, + (1 - |G1))G2 + (1- |61])(1 — |G2])63 + 
(1 - |61))(1 — [62 (1 — [63))Ga 


Y = 


con G, el promedio de las decisiones locales recibidas por el 
grupo G. 

Siendo G, el promedio de un grupo de valores [—1, 1), el 
rango de valores que puede tomar esta variable está entre -1 y 
le, [G,| = 1 cuando la decisión de todos los nodos del grupo 
G, sea unánime; Gi] = ( cuando la disparidad de decisiones 
entre los nodos del grupo G, sea máxima, es decir, haya la 
mitad de los nodos que decidan que la banda del espectro 
sobre la que han hecho la detección está libre, y la otra mitad 
de los nodos decidan que está ocupada. 

El algoritmo de decisión considera principalmente las deci- 
siones de los nodos que están en el grupo G1 para tomar la 
decisión final, ya que son los nodos que gozan de una mayor 
reputación y tienen estabilidad en el sistema. Sin embargo, 
cuando las decisiones de este grupo son muy dispares (esto 
es, el promedio de los datos en valor absoluto es bajo), el peso 
de este grupo baja y las decisiones de los grupos Ga, G3 y 
G4 toman más fuerza. Como se ha hecho con G; se analiza la 
uniformidad de las decisiones de cada grupo G, y se pondera 
consecuentemente la incidencia de este grupo en la decisión 
final. 

La decisión global se toma en función del valor y resultante. 
Si y < 0 se considera que el canal está libre. Sino, el canal 
está ocupado. 


Una vez el centro de fusión ha tomado una decisión sobre 
la ocupación del canal, la reputación y la estabilidad de los 
nodos del sistema es actualizada. 


IV. SIMULACIONES 


En esta sección se ilustran los resultados de las simulaciones 
realizadas con el esquema propuesto a través de las curvas 
ROC. Las curvas ROC representan los pares de probabilidad 
de detección (sensibilidad) frente probabilidad de falsa alarma 
para diferentes umbrales de decisión. 

Las simulaciones se han realizado con 50 usuarios secundar- 
los distribuidos aleatoriamente sobre una área de 500mx500m 
considerando un medio con obstáculos y propagación multi- 
camino. Todos los nodos secundarios utilizan un detector de 
energía para monitorizar el espectro. Por lo tanto, la SNR 
que recibe cada usuario es diferente y consecuentemente su 
capacidad de detección. El centro de fusión utiliza en cada 
caso uno de los métodos de fusión descritos en las secciones 
IT y IL 

Se ha analizado la capacidad de detección para diferentes 
métodos de detección cooperativos de uso general, que no 
requieren un conocimiento a priori sobre el contexto de 
aplicación. 


50 Usuarios 


=Ccv 
== Majority 


Probabilidad de detección (%) 
SS 
> 
z 
[o] 


o 10 20 30 40 50 60 70 80 90 100 


Probabilidad de falsa alarma (%) 


Figura 1. Gráfica ROC. Detección cooperativa con 50 nodos 


En la Fig.1 se comparan los diferentes métodos: la regla 
AND (referida como AND), la regla OR (referida como OR), 
la regla de fusión por mayoría (referida como Majority), el 
método con vectores de confianza (referido como CV) y el 
método de fusión por grupos propuesto (referido como FG). 
Los resultados muestran que el método propuesto supera al 
resto de algoritmos de fusión. Para una probabilidad de falsa 
alarma del 10% este esquema consigue una probabilidad de 
detección mayor al 10% que en el esquema de fusión por 
mayoría. 

La curva ROC evidencia que un aumento de la probabilidad 
de detección va en detrimento de la probabilidad de falsa 
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alarma y viceversa, lo que implica que la selección del umbral 
exige un compromiso entre estos dos conceptos. Para con- 
seguir los requisitos mínimos de sensibilidad y probabilidad 
de falsa alarma estipulados por el estándar IEEE 802.22 los 
valores deben ser, respectivamente, mayor al 90 % y menor al 
10% [7]. 

El segundo escenario de simulación que se ha analiza- 
do mantiene las mismas características de red que en el 
caso anterior, pero se han añadido usuarios maliciosos del 
tipo Siempre-No que atacan reiteradamente. Para evaluar el 
comportamiento de cada método, se ha fijado un umbral de 
detección para cada algoritmo que maximice la dupla de la 
probabilidad de detección y la probabilidad de falsa alarma 
en un escenario libre de atacantes. A partir de aquí, se ha 
analizado la probabilidad de detección del sistema a medida 
que se han ido añadiendo atacantes a la red. La Fig.2 evidencia 
que la regla AND es el método menos robusto frente a este tipo 
de ataques, ya que experimenta la mayor disminución. Por otro 
lado, se observa como el método propuesto cumple el estándar 
con una probabilidad de detección del 90 % para un porcentaje 
de atacantes menor al 12%. Para un porcentaje de atacantes 
mayor al 20 % no podemos asegurar probabilidad de detección, 
aunque dependiendo de la configuración de los nodos ésta 
puede ser positiva. En cuanto a la probabilidad de detección 
del método de fusión por mayoría y del método con vectores 
de confianza podemos decir que decrecen suavemente, pero 
éstos no cumplen el requisito del estándar para una proporción 
mayor al 2% de atacantes. 


---Majority 
—Cv 
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Figura 2. Probabilidad de detección con nodos atacantes 


Por último, hemos simulado un escenario con atacantes 
que actúan por ráfagas. En general los nodos tienen un buen 
comportamiento en el sistema y por lo tanto gozan de buena 
reputación, pero puntualmente pueden lanzar un ataque cuando 
ven que el éxito de éste les puede reportar algún beneficio. Las 
gráficas que se muestran en Fig.3, Fig.4 y Fig.5, representan 
la probabilidad de detección del sistema en un periodo de 
40 iteraciones. Los nodos tienen un comportamiento correcto 
durante las 10 primeras iteraciones, pero entre el intervalo de 
10 a 30 un determinado número de nodos falsifica sus datos 
reportando que el canal está libre. Finalmente, después de la 


iteración número 30, todos los nodos vuelven a enviar al centro 
de fusión los datos de detección correctos. Las características 
de la red se mantienen como en los anteriores casos, y siempre 
hay presencia de un nodo primario en la red. 

La Fig.3, la Fig.4 y la Fig.5 representan todas la prob- 
abilidad de detección frente al número de iteraciones para 
un porcentaje del 10%, del 20% y del 40% de atacantes, 
respectivamente. En las tres gráficas durante el intervalo que 
se produce la ráfaga de ataques, todos los métodos disminuyen 
su probabilidad de detección y después de este periodo vuelven 
a recuperar los valores iniciales. 

Comparando las tres gráficas observamos que los méto- 
dos de fusión por grupos, con vectores de confianza y por 
mayoría, empeoran su comportamiento a medida que aumenta 
la proporción de atacantes. Cuando esta proporción es baja, 
del 10% o del 20%, el método propuesto supera la regla de 
fusión por mayoría. En particular, para un 10% de atacantes, 
el método de fusión por grupos reacciona correctamente 
manteniéndose en una probabilidad de detección alrededor del 
90% y cumpliendo así las especificaciones del estándar. 

Si comparamos este último caso de atacantes puntuales con 
el caso de atacantes Siempre-No reiterativos (Fig.2), apreci- 
amos que los métodos de fusión sin memoria (como la OR, 
AND y Mayoría) no presentan comportamientos diferentes 
entre los dos casos. En cuanto al método con vectores de 
confianza, tiene probabilidades de detección menores que el 
método de fusión por mayoría. El método con confianza no 
está diseñado para tener en cuenta ataques puntuales, el centro 
de fusión considera correctos los informes que envían los 
atacantes que habían obtenido buenas reputaciones antes de 
atacar. El método de fusión por grupos propuesto reacciona 
correctamente frente a ataques puntuales. Observamos en la 
Fig.4 como la probabilidad de detección se encuentra alrededor 
del 70 %. Mientras que para el mismo porcentaje de atacantes 
reiterativos el método no es capaz de detectar al usuario 
primario. 
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Figura 3. Probabilidad de detección con un 10% de atacantes puntuales 
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Figura 4. Probabilidad de detección con un 20% de atacantes puntuales 
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Figura 5. Probabilidad de detección con un 40 % de atacantes puntuales 


V. CONCLUSIONES 


En este trabajo se ha descrito un esquema de detección co- 
laborativo por grupos con el objetivo de mejorar la sensibilidad 
y robustez de una red de radio cognitiva. Los resultados de las 
simulaciones muestran que el algoritmo propuesto ofrece una 
mejor probabilidad de detección frente a otros algoritmos con 
unas características de rendimiento similares. En un trabajo 
futuro se analizará la robustez del esquema en otros contextos 
y para diferentes volúmenes de nodos. 


AGRADECIMIENTOS 


Este trabajo ha sido financiado parcialmente por el Min- 
isterio de Industria, Turismo y Comercio con el proyecto 
AVANZA TSI-020100-2009-374 SAT2, y por el Ministe- 
rio de Ciencia e Innovación y los fondos FEDER con los 
proyectos TSI2007-65406-C03-03 E-AEGIS y CONSOLIDER 
CSD2007-00004 ARES. 


REFERENCIAS 


[1] LF. Akyildiz, W.Y. Lee, M.C. Vuran, and S. Mohanty. Next genera- 
tion/dynamic spectrum access/cognitive radio wireless networks: a survey. 
Computer Networks, 50(13):2127-2159, 2006. 

[2] Ruiliang Chen, Jung-Min Park, and Kaigui Bian. Robust distributed 
spectrum sensing in cognitive radio networks. In /NFOCOM. The 
27th Conference on Computer Communications. IEEE, pages 1876-1884, 
April 2008. 


376 


[3] S.P.T. Force. Spectrum policy task force report. Federal Communications 
Commission ET Docket 02, 135, 2002. 

[4] A. Ghasemi and E.S. Sousa. Opportunistic spectrum access in fading 
channels through collaborative sensing. Journal of Communications, 
2(2):71, 2007. 

[5] Sunmin Lim, Hoiyoon Jung, and Myung Sun Song. Cooperative spectrum 

sensing for ieee 802.22 wran system. In Proceedings of 18th Internatonal 

Conference on Computer Communications and Networks (ICCCN)., pages 

1-5, Aug. 2009. 

Tao Qin, Han Yu, Cyril Leung, Zhiqi Shen, and Chunyan Miao. Towards 

a trust aware cognitive radio architecture. SIGMOBILE Mob. Comput. 

Commun. Rev., 13(2):86-95, 2009. 

[7] C.R. Stevenson, C. Cordeiro, E. Sofer, and G. Chouinard. Functional 

requirements for the 802.22 WRAN standard. ¡EEE 802.22-05/0007r48, 

pages 802-22, Nov. 2006. 

E. Visotsky, S. Kuffner, and R. Peterson. On collaborative detection 

of tv transmissions in support of dynamic spectrum sharing. In /EEE 

International Symposium on New Frontiers in Dynamic Spectrum Access 

Networks (DySPAN)., pages 338-345, Nov. 2005. 

Wenzhong Wang, Weixia Zou, Zheng Zhou, and Yabin Ye. Detection 

fusion by hierarchy rule for cognitive radio. In Cognitive Radio Oriented 

Wireless Networks and Communications. CrownCom. 3rd International 

Conference on, pages 1-5, May 2008. 


[6 


== 


[8 


== 


[9 


= 


Uso de rutas cacheadas en el encaminamiento 
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Resumen—DSR is a simple and efficient routing protocol in ad 
hoc networks. This paper is based on a previous variation of the 
DSR protocol where security is added using aggregate signatures. 
Our proposal uses an additional Route Discovery Feature of 
the original protocol, to reduce the number of messages needed 
around the network to answer a Route Request. We describe 
how the cached routes of the intermediate nodes can do this 
work without losing the security level. 


I. INTRODUCCÍON 


Una red ad-hoc es aquella en la que no existe ninguna 
infraestructura de comunicación definida. Normalmente se 
define sobre dispositivos móviles y a la falta de infraestructura 
se añade la movilidad de los dispositivos que la conforman, 
por lo que el sistema es dinámico y admite variaciones. 

Debido a la falta de infraestructura predefinida y al dinamis- 
mo del sistema, para la comunicación entre nodos sin conexión 
directa se requiere la cooperación de los nodos intermedios. 
Existen múltiples protocolos específicos para este tipo de redes 
(11, 21, [31, [41, [5], [6)), en los que los métodos de 
encaminamiento tradicionales no resultan eficientes debido al 
dinamismo de los dispositivos. Estos protocolos son vulnera- 
bles al no tener en cuenta la seguridad de los mismos. Para 
entornos en los que la seguridad es un requisito importante 
se han definido protocolos de encaminamiento seguro ( [7], 
[8], [9], [10], [11]), en los que existe un compromiso entre 
nivel de seguridad ofrecido, ancho de banda, necesidad de 
procesamiento y potencia necesaria. 

Este artículo se fundamenta en el protocolo DSR [12] y 
profundiza en el planteamiento de un encaminamiento seguro 
basado en este protocolo [11]. En este esquema se emplean 
las firmas agregadas como primitiva criptográfica que permiten 
que M usuarios firmen M mensajes diferentes y las M firmas 
resultantes sean compactadas en una sola. Gracias a esta 
característica se consigue reducir el tamaño del campo de 
firmas, y por tanto, el tamaño del mensaje que se transmitirá. 
Como contrapartida tendremos que la verificación deberá ser 
realizada sobre el conjunto de las firmas, no pudiendo veri- 
ficarse cada una de ellas de modo individual. Es decir, si la 
firma final es correcta, se validan todos los mensajes que la 
componen, pero si es incorrecta, no seremos capaces de saber 
qué mensaje, o mensajes, han sido los que la han invalidado. 

El aporte que realiza este artículo, es el uso de las rutas 
cacheadas para responder a los paquetes de solicitud de ruta, 
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Route Request (RR), opción recogida en el protocolo DSR, 
manteniendo las características de seguridad preestablecidas. 
Se desarrolla un método para emplear las rutas cacheadas de 
los nodos intermedios para ofrecer un encaminamiento seguro 
que reduciría los mensajes que circulan por la red. También 
se conseguirá reducir el tiempo necesario para la obtención 
de una ruta, en el caso de que un nodo intermedio disponga 
de una ruta cacheada hacia el nodo destino requerido en el 
paquete RR. 

En la sección II se presenta brevemente el protocolo DSR y 
las firmas agregadas. En la sección III desarrollamos nuestra 
propuesta. Y en la sección IV recogemos las conclusiones y 
las líneas futuras de trabajo. 


Ill. BACKGROUND 


A continuación vamos a recordar los dos elementos funda- 
mentales sobre los que se basa nuestra propuesta: el protocolo 
de encaminamiento DSR seguro y la primitiva criptográfica de 
firmas agregadas. 


Il-A. DSR seguro 


Aunque no existe ninguna especificación estándar del pro- 
tocolo DSR seguro, sí que hay alguna propuesta sobre la mesa 
basado en DSR ( [9], [10], [11]). Empezaremos recordando el 
DSR básico, para luego explicar la versión segura de [11]. 

IT-AI. DSR: DSR es un protocolo de encaminamiento 
en el que el nodo origen establece la ruta a seguir en la 
red hasta alcanzar el nodo destino. Por tanto, en el mensaje 
de datos enviado están listadas las direcciones de los nodos 
intermedios que debe atravesar el paquete. Si un nodo tiene 
que comunicarse con otro para el que no conoce una ruta, 
envía un paquete RR, que será retransmitido por los nodos de 
la red hasta alcanzar su objetivo. Cuando el paquete RR llega 
al nodo destino, éste responderá con un paquete de respuesta, 
Route Reply (REP), en el que aparecerán los nodos intermedios 
que deben procesar los paquetes para comunicar los nodos 
extremos. 

Cada nodo mantendrá una tabla con las rutas conocidas, 
a las que se añade una marca temporal. Si una ruta no es 
utilizada dentro del margen temporal será borrada de la tabla 
de rutas conocidas. 


Figura 1: Distribución de nodos en la red ejemplo. 


II-A2. Resumen del protocolo DSR seguro: El esquema 
descrito en [11] para el descubrimiento de rutas de modo 
seguro, establece que el nodo que quiere obtener una ruta 
hacia otro nodo, genera un paquete RR que firma y propaga 
en modo multidifusión (broadcast). Los nodos que reciben el 
mensaje comprueban si son el nodo destino y en caso de no 
serlo añaden su dirección a la ruta, firman y agregan su firma 
a la anterior y propagan el mensaje en modo multidifusión. 

Cuando el mensaje llega al nodo destino, éste comprueba 
la firma agregada. Si es correcta, crea un paquete REP con 
la ruta que especificaba el paquete RR y lo envía por el 
camino inverso al que se ha recibido. Cada uno de los nodos 
intermedios recibe el paquete REP, agrega su firma al mensaje 
y lo envía al siguiente nodo de la lista. Cuando el mensaje 
llega al nodo que originó el paquete de descubrimiento de 
ruta, comprueba la validez de la firma agregada y, en caso de 
ser correcta, añade la ruta recibida a su tabla de rutas. 

IT-A3. Firmas agregadas: Las firmas agregadas son un 
concepto criptográfico relacionado con las multifirmas [13]. 
En el caso de las firmas agregadas, el escenario es un conjunto 
de usuarios U, cada uno de ellos con su par de claves pública 
y privada (K., +, Ky—). Entonces, dado un subconjunto U* CU, 
cada usuario u€U”, produce una firma cd, de un mensaje 
M,,, distinto para cada usuario. Las firmas obtenidas podrán 
agregarse formando una única firma. Para verificar la firma 
agregada será necesario tener el acceso a las claves públicas 
de los usuarios que han firmado cada uno de los mensajes, 
así como a sus correspondientes mensajes. 

Se han desarrollado firmas agregadas en paralelo [14] y 
secuenciales [15]. Las firmas agregadas en paralelo permi- 
ten su verificación sin tener en cuenta el orden en el que 
se realizó la agregación. Mientras que las firmas agregadas 
secuenciales deben ser verificadas en el mismo orden en el que 
se realizó la agregación. Existe otro tipo de esquema de firmas 
agregadas basadas en identidad [16]. Este esquema elimina 
la necesidad de certificados pero requiere de una entidad 
confiable maestra. Otra característica de las firmas agregadas 
es la longitud de la firma final, que no se mantiene constante 
para todas las implementaciones. La propuesta elegida es la 
descrita por Boneh [14], basada en aplicaciones bilineales, y 
que sí mantiene constante la longitud de la firma agregada e 
implementa un esquema de firma en paralelo. 


TII. EMPLEO DE RUTAS CACHEADAS EN DSR SEGURO 


Partimos del protocolo ya descrito [11] y de sus meca- 
nismos para realizar el descubrimiento de rutas. Al emplear 
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criptografía de clave pública, cada nodo firmará los paquetes, 
antes de proceder a su retransmisión, con su clave privada. 
Supondremos la existencia de una autoridad de certificación 
confiable AC, cuya clave pública es conocida por todos los 
nodos. La gestión de los certificados y sus revocaciones queda 
también fuera del ámbito de este trabajo, existiendo diversos 
esquemas ( [17], [18], [19]) que pueden ser utilizados. 

Con estas premisas, se va a explicar un método con el que 
se aprovechan las rutas cacheadas de los nodos intermedios 
para elaborar paquetes de respuesta de descubrimiento de ruta. 
Con ello, se consigue una respuesta más rápida y con una 
necesidad menor de recursos que los requeridos sin esta opción 
y manteniendo el nivel de seguridad previo. 


HlILA. Estructura de la tabla de rutas cacheadas 


Para poder utilizar las rutas cacheadas para responder a 
las solicitudes de ruta de otros nodos, deberemos almacenar 
el paquete con el que se haya verificado esa ruta. También 
será necesario almacenar las direcciones de los nodos origen 
y destino que originen el paquete así como el número de 
identificación de ruta asociado al mismo. La necesidad de 
almacenar estos valores radica en que son necesarios para 
elaborar la firma de los paquetes, como se explica en el 
siguiente apartado. 

Además los nodos no añadirán rutas a su tabla solamente 
cuando ellos son los que originan un paquete de RR, sino que 
cuando reciban paquetes RR y REP, también serán capaces de 
actualizar su tabla de rutas, siempre y cuando la verificación 
de las firmas sea correcta. 

Usaremos como ejemplo la distribución de nodos de la 
Figura 1 y que el nodo A inicia un descubrimiento de ruta 
hacia el nodo D. Cuando el nodo C reciba un paquete RR 
firmado por los nodos A y B, tendrá un paquete con el que 
será capaz de validar una ruta hasta el nodo A a través de B. 
De este modo, si no la conociese de antemano, añadiría a su 
tabla de rutas el camino para comunicarse con los nodos A y 
B. 

Esto que ocurre con los paquetes de RR para los nodos 
intermedios, también puede usarse con los paquetes REP. Por 
ejemplo, el nodo B recibe el paquete REP, que ha enviado el 
nodo D, y que ha pasado por el nodo C. Recibe el paquete en 
el que indica que la ruta para llegar del nodo A al nodo D es a 
través de B, el mismo, y después los nodos C y D. Al estar el 
paquete firmado por los nodos C y D, será capaz de verificar 
la validez de esa ruta para esos nodos. Así que será capaz de 
actualizar su tabla de rutas hacia los nodos C y D gracias al 
paquete REP. 


IIFB. Datos firmados de cada paquete 


Independientemente del tipo de paquete, RR O REP, se 
firmarán siempre los siguientes datos y en este orden: 
= Número de identificación de descubrimiento de ruta 
= IP origen del nodo que ha iniciado el descubrimiento de 
ruta 
= IP destino del nodo objetivo del descubrimiento de ruta 
= IP de los nodos intermedios 


KA 


Clave privada del nodo A 


agregada 


Ka+ Clave pública del nodo A 
[djKA-— Datos d firmados por el nodo A 
[dyK Mare Datos firmados por los nodos A,B y C y compactados en una firma 


[Ada KP Anc 


Datos firmados por los nodos A,B y C y compactados en una firma 
agregada. El nodo A habrá formado d, el nodo B habrá firmado dd! 
y así sucesivamente 


Tabla I: Lista de abreviaciones 


Con este formato, se unifica la estructura de los datos sobre 
los que se calcula la firma independientemente de si el paquete 
es RR o REP. 

Dependiendo de si el paquete que se está enviando es un 
RR o un REP, tendremos que los nodos intermedios componen 
una ruta completa entre los nodos origen y destino, para los 
paquetes REP, o una ruta parcial que comunica el nodo origen 
con el último de los nodos intermedios que componen la lista 
del paquete, en el caso de los paquetes RR. 

Un ejemplo del intercambio de mensajes, utilizando la 
distribución de los nodos de la Figura 1, en el que el nodo 
A quisiera obtener una ruta hasta el nodo D, sería el siguiente: 


A > multidifusión: RR || [Na, IPa, IPp] KM 4 

B > multidifusión: RR || [Na, IPa, IPp, 1Pp] KV pp 

C > multidifusión: RR || [Na,IP4,IPp, IP, 1Pc1KY ago 
D > C: REP || [Na, IPp,IPA]K4p_ || Na 

C > B: REP || [Na, Pp, IPa, Pc] KM pc- || Na 

B > A: REP || [Na, IPp, IP a, IPc, 1Pg] K4pcg- || Na 


Junto al envío de los paquetes REP, se hará necesario el 
envío del valor del identificador de descubrimiento de ruta al 
que se responde, ya que este valor, que no se envía dentro del 
paquete REP, es necesario para validar la firma. 


HC. Descubrimiento de rutas mediante rutas cacheadas 


En el ejemplo descrito en el apartado anterior, si se 
permitiese el uso de las rutas cacheadas para responder a 
los paquetes de descubrimiento de ruta y el nodo B tuviese 
una ruta almacenada para llegar al nodo D, el intercambio 
de mensajes se habría reducido hasta quedar de la siguiente 
manera: 


A > multidifusión: RR || [Na, Pa, IPp] KV 4- 
B > A: REPC || [Firma de REPC] || [Datos verif. firma] 


Se aprecia que con esta opción disminuiría el número de 
mensajes que tienen que ser enviados por la red. La firma 
que acompaña al paquete REPC, Replay cacheado, tiene la 
misma longitud que el resto de firmas del sistema. Y los 
datos extra necesarios para la verificación de la firma serán 
dos direcciones IP y un número de identificación de ruta. Por 
lo que el tamaño de los datos extra enviados será siempre 
mucho menor que el necesario para la transmisión de un único 
paquete DSR por la red. 
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Para la implementación de esta propuesta se ha diseñado 
un tipo de paquete cuyo contenido habilite a los nodos la 
verificación de firmas que asegure la fiabilidad de las rutas. 


HFCI. Contenido de REPC: El paquete REPC se compo- 
ne de dos paquetes REP dentro del mismo mensaje DSR. Esta 
opción está recogida dentro del RFC que define el protocolo 
DSR [12]. El primero servirá para validar la ruta que se ha 
seguido mediante el paquete de descubrimiento de ruta y el 
segundo validará la ruta desde el nodo intermedio hasta el 
nodo final, es decir, la ruta cacheada. Este segundo paquete 
deberá ser el que el nodo intermedio usó para validar la ruta 
entre él mismo y el nodo destino. 

La variación que habrá que realizar sobre la opción ya 
recogida en el RFC, será la utilización de un bit, dentro de 
la zona reservada, que indique al nodo que reciba este tipo 
de paquetes que la forma de procesarlo será diferente a la 
recepción de un paquete REP. Otra opción sería utilizar un 
identificador de tipo, que indicase la función del mensaje. 


1If-C2. Procesado de REPC: Cuando un nodo reciba 
un paquete REPC sabrá que va a estar compuesto por dos 
paquetes REP y que el primero de ellos deberá procesarlo 
de manera habitual, sabiendo que la confirmación de ruta 
será parcial. El segundo paquete REP incluirá una ruta que 
permita alcanzar el nodo destino desde el nodo intermedio 
que respondió al RR. 

De manera genérica, la ruta que contiene el segundo paquete 
REP no incluirá exclusivamente los nodos que conecten el 
nodo intermedio con el nodo destino, sino que formará parte 
una ruta mayor. Esto implica que la ruta a validar incluya 
nodos para los que no se ha solicitado información, pero que 
serán necesarios para realizar la comprobación de la firma del 
mensaje. 

La diferencia existente entre usar una ruta cacheada 
mediante un paquete RR o REP, será que en un paquete REP 
se firma la ruta final entre dos nodos y en uno de RR se firma 
una ruta parcial entre los nodos de origen y destino. A la 
hora de utilizar estos paquetes para añadir una ruta a la tabla 
de rutas cacheadas de un nodo no existe ningún problema. 
Pero al utilizar estos paquetes como respuesta en un paquete 
REPC, el nodo que ha solicitado el descubrimiento de ruta 
deberá ser capaz de diferenciar entre uno y otro, ya que los 
datos empleados para la firma varían dependiendo de si es un 
RR o un REP. 


Destino Saltos Aute y hera sac Slquese bitC 
validó la ruta 
A = RR [| [Na IP a, IPp]KY 4 0 
Cc _ REP || [Ng, IPp, IPg, IPo, 0 
IPp1KMpo- 
D Cc REP || [Np, IPp, IPg, IPo, 0 
IPD KYpo_ 


Tabla II: Rutas cacheadas del nodo B 


Este detalle el nodo destino del REPC lo soluciona al 
inspeccionar el paquete que responde con la ruta cacheada ya 
que, si al analizar las direcciones IP de los nodos, la última 
dirección IP de la ruta intermedia, se corresponde con el nodo 
origen, sabrá que se ha creado a través de un paquete REP. Si 
por el contrario el nodo que se indica como destino no aparece 
en la lista de nodos intermedios, se tratará de un paquete RR. 


Una vez interpretado el segundo paquete REP, el nodo 
receptor será el encargado de extraer la información parcial 
de la ruta que requiere. Para esto deberá localizar el nodo que 
originó el paquete REPC e ir añadiendo a la ruta validada en 
el primer REP los nodos hasta alcanzar el nodo destino. 


La posible aparición de bucles en la ruta final se evita 
empleando los mecanismos ya descritos para ello en el empleo 
de rutas cacheadas no seguras. Es decir, el nodo que responde 
a un RR, verifica que la ruta que va a proporcionar está libre 
de bucles. En caso de no disponer de una ruta cacheada con la 
que no forme bucles, procesará el paquete RR como un nodo 
intermedio normal y lo retransmitirá en modo multidifusión. 


Para evitar problemas en los que el tamaño y procesado 
del paquete REPC aumenten en exceso, no se permite a los 
nodos utilizar rutas aprendidas mediante rutas cacheadas para 
originar paquetes REPC. En la tabla de rutas cacheadas se 
marcará un bit en aquellas rutas que hayan sido formadas 
empleando este mecanismo, bitC. 


En cuanto a la nueva firma agregada se construye de 
forma análoga a [11]. Agregamos dos firmas construídas con 
los mismos parámetros criptográficos que contienen varias 
firmas agregadas. Dado que estamos trabajando sobre un grupo 
abeliano, las operaciones cumplen la propiedad asociativa y 
por lo tanto las firmas también. De esta manera obtenemos una 
firma de longitud igual a las dos que agregamos. Para verificar 
dicha firma sólo necesitaremos recopilar las claves públicas 
de cada uno de los signatarios agregados y los datos extra 
necesarios para reconstruir los mensajes originales firmados. 
Con esto la comprobación de la firma se convierte en un simple 
proceso de verificación de una firma agregada. 

Otra de las cuestiones que se podrían plantear sería que una 
comunicación entre A y B no garantiza que se pueda realizar 
la comunicación entre B y A. Pero tomamos como supuesto 
que la comunicación se produce en modo bidireccional. 
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IIFC3. Ejemplo de uso de ruta cacheada: Para explicar 
la generación del paquete de respuesta REPC se va a explicar 
empleando la distribución de nodos de la Figura 1. Y el caso 
en el que el nodo A inicia el descubrimiento de ruta hacia el 
nodo C. Para ello genera y transmite el mensaje formado por 
el paquete RR y la firma del mismo: 


A > multidifusión: RR || [Na, IP a, IPc] KM 4 


Cuando le llega el paquete al nodo B, este busca en su tabla 
de rutas cacheadas, Tabla 2, y como tiene una ruta almacenada 
para llegar al nodo C, inicia la generación del paquete REPC. 


Primero crea un paquete REP, como si él fuese el destino 
del paquete de descubrimiento de ruta, el cual no tendrá nodos 
intermedios ya que la conexión entre A y B es directa, y lo 
firmará. 


El paquete REP, lo genera con la ruta del paquete que 
empleó para guardar la ruta almacenada en su tabla de rutas 
cacheadas. En este caso concreto, ese paquete es un REP que 
se inició en el nodo D y cuyo destinatario era el propio nodo 
B. Como vemos, el nodo C se encuentra dentro de la ruta que 
conecta los nodos B y D. Por lo tanto, la ruta de nodos que 
indicaremos en REP será C—D y los nodos origen y destino 
asociados serán D y B. Como el nodo origen coincide con 
el último de los saltos indicados, el nodo A será capaz de 
distinguir que este paquete que emplea una ruta cacheada se 
ha llevado a cabo a través de un paquete REP y no un RR. 


Una vez que ya tiene los dos paquetes generados, el nodo 
B agrega la firma generada para el paquete REP, con la 
que tenía almacenada en la tabla de rutas, correspondiente a 
REP». En este momento ya será capaz de enviar el mensaje 
de respuesta al nodo A: 


B > A: REPC || [Firma de REPC] || Ng || IPp || 1Pg 


El nodo A será capaz con los datos facilitados de reconstruir 
los mensajes, y cada uno de los mensajes firmados por los 
nodos intermedios que componen la ruta para así verificar la 
ruta final. Es decir, será capaz de reconstruir una ruta segura 
desde A hasta el nodo intermedio B gracias a la primera parte 
del paquete REPC. Y después podrá conocer una ruta que una 
ese nodo intermedio B hasta el nodo destino C, gracias a la 
segunda parte del paquete REPC. 


Como la ruta que almacenará la habrá descubierto gracias a 
la utilización de la ruta cacheada de otro nodo, deberá marcar 
el bitC de su tabla de rutas para no emplear esta ruta como 
respuesta a un RR. 


En algunos casos, como en el del ejemplo, la ruta cacheada 
que permite a un nodo alcanzar el destino requerido, contiene 
más información de la solicitada. En este caso, el nodo A 
obtendrá también una ruta hasta el nodo D que podrá añadir 
a su tabla de rutas, marcando el bitC que indicará que conoce 
esa ruta como respuesta de una ruta cacheada. 


IV. CONCLUSION 


El empleo de las rutas cacheadas para responder a las solici- 
tudes de descubrimiento de ruta, permite disminuir el número 
de paquetes que deben ser transmitidos por la red para lograr 
una ruta válida, sin disminuir por ello la seguridad alcanzada 
en [11]. Esto se ha conseguido utilizando las opciones y los 
tipos de paquetes descritos en el RFC que define el protocolo 
DSR [12]. Como único añadido se requiere el empleo de un 
bit de la zona reservada dentro del paquete de respuesta REP. 

Además, el empleo de las rutas cacheadas ha dado como 
resultado que un nodo pueda aprender más rutas que la 
esperada y añadir más información a su tabla de rutas. 

Como futuras mejoras se plantea que en los paquetes de 
descubrimiento de ruta, habrá que establecer un método, 
normalmente mediante la activación de un bit en el RR, que 
permita paquetes REP formados con rutas cacheadas. 

El nivel de seguridad no varía de la anterior propuesta, ya 
que se emplea la misma primitiva criptográfica, sobre otro 
tipo de datos, que permiten ser verificados en una extensión 
mayor que la original. La única posibilidad que se vislumbra 
en el ataque es la posible inclusión de rutas caducadas, para lo 
que sería necesario establecer algún tipo de sincronización y 
sellado en el tiempo que será motivo de posteriores estudios. 
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Resumen—Las redes tolerantes a retrasos e interrupciones 
(DTN) no admiten los protocolos de la familia TCP/IP para el 
transporte de información ni para realizar un encaminamiento 
eficiente. Los nuevos protocolos de encaminamiento que van 
apareciendo para este tipo de redes no tienen en cuenta la 
estrecha relación entre la aplicación y la propia red. En este 
artículo se exploran los problemas del encaminamiento en redes 
DTN, haciendo especial hincapié en sus aspectos de seguridad, y 
se reflexiona sobre cómo ha de ser su diseño. Un elemento clave 
será la implicación directa de la aplicación. 


I. INTRODUCCIÓN 


Las redes basadas en la familia de protocolos TCP/IP, es decir, 
las internet, han sido aceptadas como un estándar de facto para 
las comunicaciones locales y globales de propósito general. 
Para este tipo de redes se han definido a lo largo de su existen- 
cia una multitud de protocolos subsidiarios que complementan 
sus funcionalidades, añadiendo desde maneras eficientes para 
el intercambio de información de encaminamiento, hasta es- 
quemas de protección e intercambio de claves. Incluso después 
de la llegada de la llamada inteligencia ambiental, cuando 
las redes ad-hoc móviles han vivido su época de apogeo, los 
protocolos TCP/IP han continuado en la brecha, aceptando 
nuevos mecanismos para el descubrimiento de vecinos, para 
la configuración inicial de parámetros de conectividad, o para 
el encaminamiento energéticamente eficiente, por citar sólo 
algunos. 

Recientemente, sin embargo, ha aflorado un tipo de redes 
en las que los ya tradicionales protocolos de internet no 
pueden usarse. En estas redes, llamadas generalmente redes 
con dificultades (challenged networks), existen requisitos de 
comunicación que TCP/IP no puede cumplir, como por ejem- 
plo unos tiempos de intercambio de información entre los 
nodos encaminadores superiores a los máximos previstos (IP, 
255 segundos; TCP, 120 segundos). Encontramos redes de este 
tipo en escenarios muy diversos, como las denominadas redes 
exóticas (e.g.: comunicaciones espaciales de grandes distan- 
cias, o comunicaciones submarinas basadas en ultrasonidos), 
o en situaciones en las que no existe una comunicación viable a 
corto plazo con un coste razonable. Actualmente encontramos 
estas redes bajo el epígrafe de Redes Tolerantes a Retrasos 
e Interrupciones (en inglés, Delay and Disruption Tolerant 
Networking, o DTN). 

Un grupo creado por el Internet Research Task Force (1RTF) 
y denominado Delay Tolerant Networking Research Group 
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(DTNRG [10]), ha realizado avances en la definición de 
protocolos para este tipo de redes. Así, se ha creado el Bundle 
Protocol [28], o el Licklider Transmission Protocol [25], que 
superan la restricciones y limitaciones originales de IP. Estos 
protocolos están recogidos ya en sendos documentos RFC 
(Request For Comments), por lo que ya están en el camino 
de convertirse en estándares que complementarán los de la 
familia TCPAP. Asimismo, algunos proyectos de investigación 
están realizando contribuciones en este ámbito, como es el 
caso de Haggle [9]. En paralelo, se han desarrollado otros 
mecanismos capaces de superar las limitaciones anteriormente 
mencionadas, como los basados en Agentes Móviles. 

Una de las mayores dificultades que retrasa (o bajo la 
opinión de los autores, incluso imposibilita) la aparición de 
una familia completa de protocolos de propósito general que 
dé cobertura a las necesidades de las DTN, estriba en la 
estrecha relación entre la aplicación que usa la red y la propia 
manera de operar de dicha red. 

En este artículo introducimos el problema del encamina- 
miento en redes DT'N desde la perspectiva de su seguridad, 
realizando un recorrido desde la evolución de las propuestas 
más clásicas a los protocolos y tendencias más actuales. 
Después de analizar el origen de las dificultades encontradas, 
se cuestionan las líneas actuales de desarrollo de protocolos de 
este tipo. Sin pretender solucionar este ambicioso problema, 
este trabajo ofrece unas indicaciones hacia un cambio en el 
planteamiento actual que permitirán hacer frente a las nece- 
sidades reales de encaminamiento seguro de las aplicaciones 
sobre DTN. La clave del proceso ha de estar en la delegación 
a las aplicaciones de las funciones de encaminamiento e 
intercambio de la información necesaria. Sólo de esta manera 
las DTN podrán transportar con eficiencia la información, 
sin caer en la trampa de querer encontrar en la capa de red 
una información inherente que permita tomar decisiones de 
encaminamiento. 

En el resto del artículo se introducen los protocolos de 
encaminamiento para redes DTN (sección Il) y las soluciones 
de seguridad para los mismos (sección II). Posteriormente, 
se discute la situación actual y se plantean las tesis de 
los autores sobre la evolución de los protocolos seguros de 
encaminamiento para redes DTN, basándose principalmente 
en sus experiencias en aplicaciones médicas y aeronáuticas 
para este tipo de redes. 
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II. PROTOCOLOS DE ENCAMINAMIENTO EN REDES DTN 


A diferencia de la red Internet, donde los protocolos de 
encaminamiento están bien definidos (i.e., BGP [26], RIP [22] 
u OSPF [23])), las redes DTN no disponen en la actualidad 
de un estándar ampliamente reconocido. A pesar de los 
esfuerzos realizados por el DTNRG, el cual ha elaborado dos 
borradores con propuestas diferentes ([8], [19]), la comunidad 
científica continua realizando aportaciones con alternativas 
dispares entre ellas. Parece no existir un consenso en cuanto 
a una estrategia lo suficiente genérica y válida para cualquier 
casuística. 

Seguidamente, en esta sección recogemos diversas taxono- 
mías genéricas de los protocolos de encaminamiento según los 
criterios de varios autores. El objetivo es poner de manifiesto 
la gran cantidad de propuestas realizadas. Desde el punto 
de vista de los autores, la causa de esta disgregación de 
protocolos viene motivada por las características naturales de 
las redes DT'ÍN y sus aplicaciones. Es decir, el modelo de 
encaminamiento es fuertemente dependiente de la aplicaciones 
sobre DTN. 


Il-A. Esquemas de encaminamiento según el conocimiento 
de la topología de la red 


Podemos encontrar una clasificación de los protocolos de 
encaminamiento en [11], la cual tiene en cuenta el nivel de 
conocimiento sobre las características de la topología de la red 
y la demanda de tráfico que tienen los nodos. Farrell, según 
este criterio, identifica los siguientes tipos de encaminamiento: 


= Basado en oráculo: un nodo o un conjunto de nodos 
(oráculos) tiene un conocimiento casi total de la red y 
de cómo evolucionará. Este conocimiento es utilizado 
por los oráculos para distribuir información de encami- 
namiento en la red que será empleada para determinar la 
ruta. 

= Basado en modelo: los algoritmos de encaminamiento 
utilizan perfiles de comportamiento conocidos con el 
objetivo de seleccionar las rutas. 

= Epidémico: basado en la propagación masiva de la 
información entre todos los nodos (flooding), sin tener 
un conocimiento preciso de cuál será la ruta final. 

= Basado en estimación: estos algoritmos priorizan las ru- 
tas estimando probabilidades, de manera que maximizan 
el reenvío de un paquete hacia un nodo en particular 
sabiendo que así se aumentará la probabilidad de entregar 
el paquete al destino final. 

= Erasure coding: estos protocolos de encaminamiento 
emplean estrategias basadas en la teoría de códigos, 
concretamente los erasure codes [21]. Se fundamentan en 
transformar un mensaje de n símbolos en uno de longitud 
mayor con k símbolos, de manera que un subconjunto de 
los k símbolos permite reconstruir el mensaje original. 
Los algoritmos de encaminamiento son los responsables 
de crear y enviar dichos k símbolos, con el objetivo de 
que un subconjunto permita recuperar el mensaje original 
en el destino. 


= Basado en control del movimiento de los nodos: a 
esta categoría pertenecen aquellos esquemas en los que el 
algoritmo de encaminamiento es utilizado para controlar 
el movimiento físico de los nodos. 


II-B. Estrategias de encaminamiento basado en la propaga- 
ción de los mensajes 


De acuerdo con Balasubramanian y Nelson podemos conside- 
rar la siguiente taxonomía basada en las réplicas de un mensaje 
(14), [24)): 
= Basado en reenvío: mantiene una única copia de un 
mensaje en la red e intenta reenviarla hacia el destinatario 
en cada encuentro. Algunos de los protocolos que se 
engloban en esta categoría los encontramos en [16], [17] 
y [31]. 
= Basado en replicación: inserta múltiples copias (o répli- 
cas) de un mensaje en la red para incrementar la proba- 
bilidad de entrega. Los protocolos basados en replicación 
intentan balancear el compromiso entre los recursos 
utilizados y la probabilidad de entregar un mensaje. Los 
protocolos propuestos intentan limitar la replicación o 
eliminar las réplicas no útiles según diversos criterios 
como: 


e Utilizar información histórica de encuentros. 

e Eliminar réplicas utilizando paquetes de confirma- 
ción de mensajes entregados. 

e Utilizar información probabilística de movilidad pa- 
ra inferir las entregas. 

e Replicar mensajes con una probabilidad baja. 

e Emplear códigos con redundancia. 

e Establecer un número máximo de réplicas. 


En la categoría de replicación podemos identificar dos 
subcategorías: 


e Basado en flooding: envía una replica de cada 
mensaje a tantos nodos como sea posible. Algunos 
protocolos propuestos son Epidemic [36], PROPHET 
[20], MaxProp [7] o RAPID [4]. 

e Basado en cuota: limita el número de replicas. 
Algunos de los algoritmos que pertenecen a esta 
categoría son Spray and Wait [32], Spray and Focus 
[30] o Encounter-Based [24]. 


= Estrategia híbrida: combina conceptos de encamina- 
miento basado en reenvío y replicación. A esta categoría 
pertenece el Hybrid Probabilistic Routing Scheme Using 
Multi-Copies (HUM) [18]. 


II-C. Esquemas de encaminamiento según accidentalidad o 
intencionalidad 


En [4] podemos encontrar otra categorización basada en los 
conceptos de accidentalidad o intencionalidad respecto a una 
cierta métrica de rendimiento. Alguna de estas métricas pueden 
ser el tiempo promedio de retraso o la probabilidad de entrega 
entre otros. 


= Accidentalidad: esquemas que sólo tienen un efecto de 
mejora fortuito sobre una métrica de rendimiento. 


384 


= Intencional: esquemas que de forma intencionada pre- 
tenden optimizar una métrica de rendimiento escogida. 


Il-D. Encaminamiento basado en constricciones de recursos 


Balasubramanian et al. proponen en [4] una taxonomía de los 
algoritmos de encaminamiento considerando si éstos tienen en 
cuenta unas constricciones de recursos o no. Entre dichas cons- 
tricciones podemos encontrar la capacidad de almacenamiento 
de los nodos, el ancho de banda o el consumo energético. 


TIIl. SEGURIDAD EN REDES DTN 


En la actualidad disponemos de un amplio conjunto de me- 
canismos que nos proporcionan seguridad en las redes. Sin 
embargo, estos mecanismos tradicionales, como son los pro- 
tocolos criptográficos SSL o TLS, no pueden ser trasladados 
a las redes DTN de forma directa. El motivo de esto radica 
en el hecho de que dichos mecanismos parten de una serie de 
asunciones no propias de las redes tolerantes a retrasos, tales 
como una conectividad permanente punto a punto, o retrasos 
pequeños a nivel de capa de enlace entre otros. Por este 
motivo, nuevos protocolos y arquitecturas deben ser diseñadas 
basándose en las características inherentes a las redes DTN. 
De acuerdo con esto, en la presente sección analizaremos 
la seguridad desde dos perspectivas relevantes: la gestión de 
claves criptográficas y el encaminamiento seguro. 


IIFA. Gestión de claves criptográficas 


Actualmente, el Delay Tolerant Networking Research Group 
está definiendo las especificaciones necesarias para propor- 
cionar seguridad en las redes DT'N. Concretamente, se han 
publicado dos documentos en forma de RFC y de borrador 
para el Licklider Transmission Protocol (LTP) y para el Bundle 
Protocol (BP) respectivamente. 

En el caso del LTP, la seguridad viene definida a través del 
RFC 5327 [13], donde se plasman las extensiones de seguridad 
necesarias para garantizar la autenticidad de los fragmen- 
tos. Análogamente, se propone evitar posibles ataques DoS 
mediante la utilización de valores aleatorios —denominados 
cookies— que son añadidos a las cabeceras de los fragmentos. 

En el caso particular del protocolo bundle, se ha pre- 
sentado un borrador [35] que recoge las especificaciones 
para proporcionar seguridad. En dicho borrador se definen 
cuatro bloques que pueden ser añadidos a las cabeceras del 
protocolo bundle con la finalidad de proporcionar diversos 
servicios de seguridad. De forma concreta, éstos son el Bundle 
Authentication Block (BAB), el Payload Integrity Block (PIB), 
el Payload Confidentiality Block (PCB) y el Extension Security 
Block (ESB). 

En ambos documentos se define un conjunto de funciones 
criptográficas a emplear de forma mandatoria, como pueden 
ser RSA, SHA o AES. Así pues, la criptografía es propuesta 
como una herramienta a emplear para resolver los problemas 
característicos de seguridad de confidencialidad, integridad y 
autenticidad. Sin embargo, tanto en las mismas propuestas del 
DTNRG como en otras referencias ([2], [3], [11], [1], [29]) se 
reconoce abiertamente que la distribución y gestión de claves 


en las redes D'T'N es un problema abierto y vivo desde la 
perspectiva de la investigación. 

Tradicionalmente, el problema de la gestión de claves ha si- 
do resuelto mediante las infraestructuras de clave pública (PKI 
- Public Key Infrastructure). Sin embargo, esta arquitectura 
no puede emplearse en entornos tolerantes a desconexiones 
y retrasos como son las redes DTN. Así, un emisor en una 
red DTN no siempre dispondrá del certificado digital del 
destinatario que necesite. Hay que considerar, a su vez, que 
ante una situación similar tampoco tenemos la garantía que 
éste pueda acceder a un repositorio de donde obtener el 
certificado. Del mismo modo, garantizar la autenticidad de los 
certificados implicaría que cada nodo almacenase un conjunto 
de certificados asociados a las autoridades de certificación de 
confianza. Este hecho, y dependiendo del número de certifica- 
dos, puede conducirnos a una situación inadmisible motivada 
por las restricciones de capacidad de almacenamiento de 
determinados nodos. De forma similar, podemos considerar 
que la actualización de los certificados de revocación y su 
almacenamiento supone una problemática en entornos DTN. 

Diversas ideas en este área han sido propuestas hasta 
la fecha para solventar algunas de las problemáticas vistas 
anteriormente. Así, tal y como se expone en [12], la adopción 
del esquema duckling —propio de las redes ad-hoc— podría 
ser una primera aproximación a la solución. Dicho esquema, 
propuesto en [34] y extendido en [33], propone el intercambio 
de claves entre nodos que tienen una alta probabilidad de 
conectividad con el resto, almacenándolas y reenviándolas a 
otros nodos en futuras conexiones oportunistas. A pesar de 
esto, la adopción de este esquema no resuelve el problema en 
su totalidad debido a su no-determinismo, ya que no garantiza 
que los nodos dispongan de todas las claves públicas en 
cierto instante de tiempo. De forma similar, la autenticidad 
de las claves reenviadas es un problema no resuelto por este 
esquema. Podemos notar que la revocación de claves tampoco 
es solventada, ya que el envío de las listas de actualizaciones 
con las claves revocadas podría postergarse excesivamente en 
un contexto de desconectividad como son las redes DTN. 

Una alternativa para resolver los problemas anteriores se 
fundamenta en emplear claves basadas en la identidad de los 
nodos. Esta idea, conocida como Identity Cryptography-Based 
(IBC [5]), es propuesta por Asokan et al. para DTN en [2] 
y en [3]. A diferencia de las PKI tradicionales, donde un 
usuario obtiene las claves de una autoridad de certificación, en 
IBC la clave pública es construida a partir de un identificador 
vinculante a cada nodo, mientras que la clave privada es ge- 
nerada por una tercera parte de confianza denominada Private 
Key Generator (PKG). De esta manera, para un emisor, la 
obtención de una clave pública de un destinatario se transforma 
en un proceso trivial y carente de cualquier comunicación 
con repositorios de claves. El problema de la revocación de 
claves es resuelto mediante la construcción de identificado- 
res (1.e., claves públicas) temporales. Así, un identificador 
es utilizado por un corto periodo de tiempo, y construido 
mediante la concatenación de un identificador fijado para 
un nodo y destinatario junto a su periodo de validez (e.g., 
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alicetdtn-node.com: 23-04-2010). Mediante esta estrategia, 
la revocación de claves es evitada al refrescar los identifica- 
dores de forma periódica. Podemos encontrar algunas mejoras 
sobre el esquema IBC presentadas en [29], y denominada 
Hierarchical Identity Based Cryptography (HIBC). 


IIFB. Encaminamiento y seguridad en DTN 


Desde el punto de vista del encaminamiento, el algoritmo 
empleado en una red DTN tiene una fuerte influencia en 
las propiedades de seguridad del sistema. Así, mientras que 
determinadas estrategias de encaminamiento pueden ser dise- 
ñadas sin mecanismos de autenticación, otras podrían necesitar 
de éstos como condición sine qua non para su correcto 
funcionamiento. Así, por ejemplo, en [6] se plantea cómo 
una estrategia de encaminamiento adecuada, sin el uso de 
mecanismos de autenticación entre nodos intermedios, pue- 
de llegar a ser efectiva. Asimismo, la utilización o no de 
autenticación en el proceso de encaminamiento no elude la 
necesidad de autenticación y/o confidencialidad de extremo a 
extremo entre aplicaciones. En este sentido, y tal como ocurre 
hoy en día en la red Internet, podemos notar también una 
dependencia entre las características de seguridad del sistema 
y los requisitos de las aplicaciones. Así, podemos pensar que, 
por ejemplo, determinadas aplicaciones no críticas no tienen 
porque garantizar la confidencialidad de la información que 
viaja entre los nodos de la red DTN, mientras que para otras 
suponga una necesidad indispensable. 

Como sugiere Farrell en [11], es necesario que los proto- 
colos y las implementaciones soporten mecanismos de enca- 
minamiento basados en políticas. Es decir, cada protocolo de 
DTN debería especificar qué variables de seguridad tienen que 
ser consideradas desde el punto de vista del encaminamiento, 
de manera que las implementaciones puedan tomar decisiones 
en cuanto al encaminamiento y el reenvío de bundles. Esto 
cobra especial sentido si tenemos en cuenta que el reenvío 
o almacenaje de un bundle supone un consumo de recursos. 
En particular, dado que el reenvío de un bundle implica un 
gasto de recursos (en términos de espacio, energía, etc... ), un 
nodo debería ser capaz de incorporar una política de encamina- 
miento que le permitiese tomar una decisión al respecto. Así, 
por ejemplo, un nodo intermedio podría exigir que todos los 
bundles de entrada debieran ser autenticados, en caso contrario 
éstos serían rechazados. 


IV. HACIA UN ENCAMINAMIENTO SEGURO ORIENTADO A 
LA APLICACIÓN 


Según hemos visto hasta ahora, pese a disponer ya de di- 
versos mecanismos para el transporte de la información y su 
encaminamiento en redes DTN, aun no es posible aprovechar 
estas redes en todas sus posibilidades. El problema en si tiene 
dos vertientes: por una parte, necesitamos que las unidades 
de información puedan ser dirigidas hacia los nodos que 
ofrezcan una mayor probabilidad de llegada al destino bajo 
las restricciones impuestas por la red y la aplicación; por otro 
lado, precisamos de esquemas de seguridad que sean robustos 
a la no contemporaneidad de las comunicaciones (los extremos 


pueden no estar conectados a la red simultáneamente), propia 
de las DTN. Ni lo uno ni lo otro encuentra en el estado del arte 
actual unas soluciones viables, pero analicemos aquí si existen 
otras tecnologías o líneas de investigación que cumplan para 
con estos propósitos. 


IV-A. Encaminamiento 


Veamos primero el caso del encaminamiento. Un punto im- 
portante que no debe olvidarse aquí es que, a diferencia de 
las redes ad-hoc móviles (MANET), el mejor nodo hacia 
el cual re-encaminar la información no es necesariamente el 
que está a menor distancia (de hecho, podemos suponer que 
la mayoría de los destinos no está accesible en ese preciso 
instante); ni siquiera, como sucedía usualmente en las redes 
de sensores inalámbricas, al que está a menor distancia física. 
Sólo las aplicaciones saben decidir el mejor camino ante un 
conjunto de vecinos. Por tanto, la no disponibilidad simultanea 
de las partes comunicantes, combinada con la movilidad de los 
nodos encaminadores (store, carry and forward), hacen que 
sea imposible predecir a nivel de red qué vecino es el mejor 
candidato para re-encaminarle la información. 

La solución más evidente es dejar decidir a la propia 
información. Es decir, la unidad básica de transmisión puede 
llevar código implementando el algoritmo de encaminamiento. 
También, como no, para la actualización de la información 
acerca de nodos remotos que utilizará ese algoritmo. El tipo 
de encaminamiento va a depender, no ya de las características 
de la red subyacente, sino de la propia aplicación. Las apli- 
caciones utilizan la red de forma muy diferente dependiendo 
de sus objetivos particulares. Un ejemplo sería una red DT'ÍN 
constituida por autobuses urbanos. Para una aplicación, el 
algoritmo de encaminamiento podría utilizar el identificador 
de la línea de autobús de cada vecino, ya que podría conocer a 
priori los enlaces y por tanto decidir de manera correcta; otra 
aplicación, en el mismo instante, podría utilizar un criterio 
diferente, como si aquel autobús en concreto ya ha sido 
visitado anteriormente por el agente. 

El código móvil, y particularmente los agentes móviles, 
son una alternativa clara a los esquemas actuales de enca- 
minamiento en redes DTN, y permiten implementar las ideas 
expuestas. En este caso, debe considerarse que existe un doble 
transporte de la información: el de los nodos físicamente 
móviles, y el de los agentes, que transportarían los datos a 
distancias de uno o más nodos. Así, varias aplicaciones darían 
lugar a diferentes tipos de agentes, cada uno con sus propios 
algoritmos de encaminamiento operando simultáneamente. 
Para el intercambio de información de encaminamiento se 
necesitaría una estructura más compleja, que podría consistir 
en una organización basada en ontologías. 


IV-B. Seguridad 


Una vez vistas las consideraciones sobre el encaminamiento, 
enlazamos con la cuestión prioritaria: la seguridad. En la 
sección III hemos visto los diferentes esquemas de seguridad 
que se han planteado hasta el momento relacionados con las 
redes DTN. Hemos concluido que ninguno de los esquemas 
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propuestos constituye una solución válida de propósito ge- 
neral, puesto que al final la mayoría presupone la existencia 
y accesibilidad de algún componente generalmente utilizado 
para la gestión de claves. Ésto, en una red DIN, plantea un 
requisito difícilmente alcanzable. 

Por tanto, no nos sirven para las DTN los esquemas de 
seguridad que se basan en el establecimiento eventual de una 
conexión a un punto centralizado. Una propuesta interesante 
es la denominada criptografía basada en la identidad, o IBC, 
donde una parte de confianza genera las claves privadas que 
corresponden a identificadores, que hacen a su vez de clave 
pública. IBC, combinada con [35] sí plantea un escenario via- 
ble para el uso de criptografía de clave publica en escenarios 
DTN. No obstante, hay que tener en cuenta varios aspectos. En 
primer lugar, IBC añade en las identificaciones/claves públicas 
información sobre el periodo de validez de la clave con el 
claro objetivo de no requerir un sistema de revocación de cer- 
tificados basado en el intercambio de listas. Para su utilización 
en DTN debe considerarse que los nodos, dependiendo de la 
red, pueden estar días o incluso meses desconectados y que, 
por lo tanto, los periodos de validez deberían ser largos. Esto 
puede afectar a la robustez del esquema, dependiendo de la 
IBC concreta utilizada. El acceso al productor de claves (PKG) 
en IBC en ciertos escenarios DT'N puede llegar a ser también 
un problema insalvable. 

Los agentes móviles también aportan una alternativa para 
afrontar el problema de la seguridad de la información (de 
encaminamiento o no) en las redes DT'N. Existen propuestas, 
como [14] y [15], que dotan a los agentes de la capacidad de 
decidir y aplicar sus propios esquemas de seguridad, al margen 
de los entornos de ejecución. En este caso, las unidades de 
información están auto-protegidas. 

Cuando por las especificidades de la aplicación o la red 
no pueda usarse ninguno de los enfoques clásicos, ni de los 
mencionados hasta ahora, también se puede recurrir a esque- 
mas basados en modelos de confianza [27]. La reputación, 
por ejemplo, ganada por los nodos en un histórico reciente 
de interacciones, podría usarse de manera combinada con un 
sistema dinámico de recomendaciones para valorar el riesgo 
de atentados contra la seguridad de las comunicaciones, O para 
aplicar técnicas de ostracismo a los nodos problemáticos. 


V. CONCLUSIONES 


Las redes DTN presentan unos requisitos nada fáciles de cum- 
plir, tanto por lo que se refiere al transporte de la información, 
como a su encaminamiento, y especialmente en cuanto a su 
seguridad. A lo largo de este artículo se han explorado los 
diferentes mecanismos que existen hoy en día para hacer frente 
a todos estos problemas, con el objetivo final de determinar 
si una combinación de los mismos es suficiente o si por el 
contrario debe plantearse otro tipo de soluciones. 

Después de la revisión de mecanismos realizada en las 
primeras secciones de este trabajo, y de las reflexiones en la 
sección anterior, una de las primeras y más claras conclusiones 
que extraemos es que las líneas de investigación basadas en un 
enfoque clásico, continuista de los protocolos de Internet, no 


solucionarán los problemas en las DTN. En este tipo de redes, 
las aplicaciones adquieren un alto nivel de protagonismo que 
en muchos casos pasan a ser ellas las únicas capacitadas para 
la toma de decisiones. 

Unas de las maneras más evidentes de dotar a las aplicacio- 
nes de estas capacidades, sin mezclar la implementación de 
la funcionalidad principal con la de la gestión de la red, es 
a través del uso de agentes móviles. Esta manera de hacer se 
desmarca completamente de la seguida hasta el momento por 
el DTNRG, que siguen el modelo de IP hasta donde es posible 
y quedan bloqueados cuando hay que aportar una solución a 
los problemas más duros. Los agentes móviles pueden ser el 
impulso necesario para salir de esta solución de máximo local. 

Muchas de las soluciones concretas que hemos revisado 
implican que todos los elementos de la red deben usarlos 
del mismo modo, por ejemplo un determinado algoritmo de 
encaminamiento. En este aspecto, los agentes móviles nos 
permiten una convivencia entre diferentes esquemas, sin que 
se interfieran entre ellos y facilitando enormemente las tareas 
de mantenimiento (como la corrección de errores). 

Los agentes móviles nos ofrecen una manera completa de 
tener mecanismos de encaminamiento en redes D'T'N con apli- 
caciones heterogéneas, y al mismo tiempo posibilitan añadir 
seguridad, y por extensión, encaminamiento seguro que es lo 
que buscábamos en un principio. 

No estamos ante una solución ya preparada para solventar 
todos los problemas que plantean las DT'N. Para poder utilizar 
los agentes móviles en DTN se deben integrar mecanismos en 
los mismos que diferencien la ejecución autónoma que los 
caracteriza, con otra no autónoma, de soporte de decisión de 
encaminamiento, o de actualización de información de enca- 
minamiento. Para realizar todo esto se necesita un planificador 
del encaminamiento para agentes móviles en DT'N, que podría 
incorporar también una gestión de prioridades. 

Al margen de los agentes móviles, y cuando por cuestiones 
de la aplicación o de la red no puedan usarse los esque- 
mas revisados, puede recurrirse a una solución basada en la 
confianza. Esquemas de reputación y recomendación serían 
mecanismos que permitirían, después de un tiempo transitorio, 
disponer de una protección tácita contra ataques. 
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Abstract—Los protocolos de almacenamiento, transporte y 
reenvío, store, carry and forward, para redes DTN, redes tole- 
rantes a retrasos, y en particular el protocolo Bundle protocol, 
ofrecen nuevas posibilidades en escenarios donde la interconexión 
es intermitente, los anchos de banda son asimétricos, las latencias 
son altas y variables y los patrones de movilidad son ambiguos. 
En el contexto del protocolo Bundle protocol, sus unidades 
de protocolo, los bundles, permanecen acumulados durante un 
tiempo en los nodos DTN hasta que otro nodo acepte su 
custodia. En algunos escenarios DTN, este tiempo puede ser 
inadmisiblemente elevado. Bundles considerados cruciales pueden 
permanecer bloqueados por mucho tiempo, mientras otros menos 
importantes son liberados. Por otro lado, los agentes móviles 
son un modo excelente de implementar redes DTN ya que 
pueden transportar los bundles o directamente información de 
aplicación y a la vez ejecutar código. Las plataformas encargadas 
de permitir la ejecución de los agentes móviles, conservan éstos 
hasta que otra plataforma acepte su migración. Las migraciones 
de los agentes móviles pueden ser planificadas usando políticas 
dinámicas para evitar que agentes móviles importantes sean 
bloqueados. Estas políticas pueden viajar con los mismos agentes 
móviles. Este artículo describe los problemas de seguridad que 
puede comportar este tipo de escenarios. 


I. INTRODUCCIÓN 


En los últimos años están apareciendo unos nuevos tipos 
de redes, las llamadas redes con dificultades (challenged 
networks) para las que los habituales protocolos de Internet, la 
familia TCP/IP, no son válidos. Los principales motivos son 
la no contemporaneidad de las comunicaciones, y la preva- 
lencia de las interrupciones, desconexiones, grandes retrasos, 
e intermitencias, lo que invalida todos aquellos protocolos 
con un tiempo máximo de espera o vida de las unidades de 
información, como IP (255 segundos), o TCP (120 segun- 
dos). Entre estas redes se encuentran la redes inalámbricas 
dinámicas, redes de sensores heterogéneas, y las denominadas 
redes exóticas, que incluyen las submarinas de ultrasonidos 
y las interplanetarias. Recientemente se está realizando un 
esfuerzo de investigación sobre estas redes, bajo el epígrafe 
de Redes Tolerantes a los Retrasos e Interrupciones (en inglés, 
Delay and Disruption Tolerant Networking, DTN), y el IRTF 
(Unternet Research Task Force) ha creado un grupo con el 
objetivo de promover una serie de protocolos que les den 
cobertura [2]. 

Las características de las DTN hacen muy difícil, sino im- 
posible, disponer de mecanismos eficientes de encaminamiento 
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usando exclusivamente información de nivel de red. Los 
Agentes móviles [3] son una alternativa a los recientemente 
aparecidos protocolos de transporte de información para DTN 
([1]), Licklidder Transport Protocol [8]), basados éstos últimos 
en el enfoque clásico del encaminamiento y continuista en 
las líneas de TCP/IP. En este tipo de redes, las propias 
aplicaciones suelen disponer de información relevante para el 
encaminamiento, y la habitual separación entre información 
de las capas de red, transporte y aplicación queda obsoleta. 
Aquí, los agentes móviles permiten delegar el proceso de 
encaminamiento (y re-encaminamiento) a la capa de apli- 
cación, permitiendo viajar al mismo tiempo a información y 
algoritmos de routing. 

Implementar una red DTN con agentes móviles aplicando 
las ideas expuestas no es una tarea sencilla. En este ar- 
ticulo proponemos precisamente las bases de un esquema 
para conseguirlo, centrando en el diseño del planificador de 
la migración en la plataforma (entorno de ejecución de los 
agentes móviles), y preservando al máximo la independencia 
entre la programación de la aplicación y de los algoritmos 
de encaminamiento. Se hace especial énfasis en su seguridad, 
ya que los planificadores serán los elementos clave del fun- 
cionamiento de la red entera, y por tanto su talón de aquiles. 

En el resto del artículo se analizarán las redes D'TN basadas 
en agentes móviles (sección Il), y los retos de seguridad aso- 
ciados al planificador (sección III). Finalmente, se establecen 
los fundamentos para una arquitectura segura para redes DTN 
basada en agentes móviles (sección IV). 


II. REDES DTN BASADAS EN AGENTES MÓVILES 


Las redes DTN tradicionales usan el protocolo Bundle pro- 
tocol [1] para gestionar el paradigma store-carry-and-forward 
(almacenamiento, transporte y reenvío). Como se propone en 
la figura 1 podríamos complementar la capa bundle con una 
infraestructura basada en agentes móviles. 

La información de aplicación viaja usando la infraestructura 
de las redes DTN representada en la figura como la capa DTN. 
Esta capa D'T'N puede ser implementada por un lado usando 
el protocolo Bundle protocol o por otro prescindiendo de 
éste y usando agentes móviles. Ambas opciones necesitan un 
nivel de convergencia por debajo, el cual puede ser protocolos 
basados en protocolos TCP/IP, el protocolo DTN Licklider 
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Transmission Protocol [8] sobre cualquier nivel de enlace o 
directamente sobre un nivel de enlace. 


Nuestra propuesta consiste precisamente en añadir esta 
alternativa. El objetivo es conseguir, usando agentes móviles, 
el paradigma store-carry-and-forward. Si suponemos que la 
plataformas de los agentes móviles pueden estar desconectadas 
esporádicamente, estamos ante una posible arquitectura DTN. 
El almacenamiento son los agentes móviles mientras que 
ejecutan su código junto al tiempo de espera bloqueados en la 
cola de la plataforma. El transporte es la misma plataforma 
en el caso de que sea una plataforma en movimiento. El 
reenvío, en cambio, es la migración del agente móvil. Por 
tanto, información que viaje dentro de un agente móvil y vaya 
saltando de plataforma en plataforma, cuando éstas pueden 
estar esporádicamente desconectadas, es decididamente infor- 
mación del nivel de aplicación de una red DTN. 


Application data 


Application Layer 


Mobile Agents 


Fig. 1. 


Capas DTN 


En la figura 2 se puede ver como todas estas arquitec- 
turas diferentes planteadas pueden convivir unas con otras. 
En la misma figura, inicialmente un agente móvil transporta 
directamente información del nivel de aplicación. El agente 
ante estas interrupciones, desconexiones, grandes retrasos, e 
intermitencias, al migrar, se comporta como una mula [11] 
efectuando un carry activo, es decir transportando activamente 
la información del nivel de aplicación. Un nodo custodio DT'ÍN 
en movimiento, como podría ser una barca, un avión o un 
animal que disponga de una plataforma de agentes móviles, 
al desplazarse, realiza un carry pasivo. Es este caso, no existe 
ninguna entidad software que efectúe el transporte, sino que 
es el movimiento físico del nodo custodio quien produce el 
carry. Siguiendo con el flujo de los datos de aplicación de la 
figura 2, el agente móvil transportado por el nodo custodio 
en movimiento podría llegar a un escenario en el que ya no 
se dispone de plataformas de agentes móviles, pero si de la 
infraestructura clásica del protocolo Bundle protocol. En este 
caso, el agente móvil podría ser serializado y viajar dentro 
de un bundle. Una vez en un escenario con plataformas de 
agentes móviles disponibles, el agente podría ser revivido y 
continuar hacia su destino. Por último, un agente móvil podría 
incluso querer transportar un bundle. Al llegar a una red DTN 
tradicional sin plataformas de agentes móviles debería ser 
capaz de suicidarse, sin antes crear una réplica del bundle 
que lleva dentro. 


Info aplic. sobre Agente E 
"Carry" pasivo : 


Bundle transp. Agente 


bundle 


Fig. 2. Distintos escenarios DTN 


A. Planificación de agentes móviles 


El objetivo de permitir a los bundles o a la información 
de aplicación ser transportados por agentes móviles, es 
aprovechar la posibilidad de que los agentes móviles son 
capaces de tomar decisiones en cada uno de los saltos entre no- 
dos custodio. En redes DTN el contexto puede ser modificado 
lo suficientemente para pensar que se necesita una manera más 
dinámica de resolver los problemas subyacentes de este tipo de 
redes. Para poder conseguir este dinamismo, pensamos que la 
unidad de protocolo bundle debería, de alguna manera, poder 
ejecutar código. Este código ayudará a mejorar aspectos de las 
redes DT'N como el encaminamiento, la congestión, el control 
de flujo, la fiabilidad y a disminuir los retrasos. Así como el 
poder ejecutar código nos permitirá más flexibilidad, será la 
fuente mayor de problemas de seguridad. 

El objetivo de planificar las migraciones de los agentes 
móviles en las plataformas es priorizar determinados agentes 
móviles sobre otros, dados unos criterios. La necesidad de la 
priorización se encuentra en el hecho que la plataforma destino 
donde un agente móvil planea migrar podría estar disponible 
sólo por un cierto tiempo. Cuanto antes se permita migrar a 
los agentes móviles más prioritarios, mejor. Por ejemplo, en 
escenarios de recuperación ante desastres, un agente móvil 
que contenga información relativa a víctimas de estado grave, 
debería poder migrar antes que otro agente que contenga 
información sobre víctimas de estado leve. 

La utilidad y la viabilidad de este sistema se ha medido 
usando tres escenarios diferentes. En los tres escenarios, varios 
nodos DTN con plataformas corriendo en cada una de ellas, 
se desconectan de la red esporádicamente y van recibiendo 
sendos agentes móviles. En las abscisas se representa el 
número de agentes y en las ordenadas el tiempo de mejora 
de los agentes priorizados sobe el resto de agentes móviles 
durante la prueba. 

Se define un primer escenario en el que la densidad de 
agentes móviles es alta sobre una plataforma en concreto, un 
segundo escenario en el que el patrón de migración es aleatorio 
y un último escenario en el que, al contrario de los otros dos 
escenarios, el número de agentes priorizados es alto. Se puede 
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ver en la figura 3 que a partir de cierto número de agentes 
móviles, la mejora sobre la media del resto de los agentes es 
considerable. 


Prioritized agents over total mean 


Dense scenario. —— 
Random scenario. —==— 
High number of prioritized. —+*— 


Seconds less than the average 


Number of agents 


Fig. 3. Agentes móviles priorizados 


TIT. RETOS DE SEGURIDAD 


En esta sección se describirán los problemas de seguridad 
derivados del uso de planificadores de agentes móviles para es- 
cenarios de redes DTN. En la siguiente sección se propondrán 
soluciones generales para los problemas propuestos. 


A. Criterios de planificación 


Los criterios para priorizar las migraciones de los agentes 
móviles podrían cambiar eventualmente en cualquier mo- 
mento. Complementando el ejemplo de la sección anterior, 
ante un desastre natural de gran envergadura, los criterios 
para priorizar agente móviles que transportan información de 
nivel de aplicación sobre víctimas, pueden variar según las 
circunstancias. 

Para informar a plataformas de criterios nuevos se utilizan 
los mismos agentes móviles que actúan a modo de piggy- 
backing transportando información relativa a las prioridades. 
Cuando un agente móvil llega a una plataforma, la primera 
acción que toma es comprobar que la información sobre los 
criterios de planificación están actualizados. En el caso de que 
la información que disponga el agente móvil sea más reciente 
que la disponible localmente en la plataforma, el agente 
móvil actualizará ésta última. La estructura donde los agentes 
móviles pueden leer y escribir sobre criterios de prioridad es 
una estructura local donde, a modo de pizarra, los agentes 
móviles pueden leer y escribir. Los autores ya han experi- 
mentado con escenarios similares en los que agentes móviles 
actualizan información dinámica en nodos heterogéneos en 
entornos de computación distribuida grid [16]. 

No podemos confiar en el hecho de que en todo momento 
la información sobre nuevos criterios de planificación se 
propague por todos las plataformas usando nada más los 
agentes móviles que transportan la información de bundles o la 
información de aplicación, es decir los agentes convencionales. 
Por ello, se han definido un tipo de agente móvil especial cuya 


función es viajar de plataforma en plataforma manteniendo los 
criterios actualizados. 

Esta estructura común en la que los agentes móviles pueden 
leer y escribir es una primera fuente de problemas de seguri- 
dad. La información está estructurada en forma de árbol, donde 
cada rama de éste es una ontología distinta, como se puede ver 
en la figura 4. Agentes móviles pertenecientes a la ontología 
de la medicina, por ejemplo, debería poder leer o escribir nada 
más bajo la rama perteneciente a la ontología médica. Tanto si 
se trata de los agentes especiales, como de los convencionales, 
se necesita garantizar por tanto, que el acceso a la estructura 
se cumpla la confidencialidad, la autenticación, la integridad 
y el no repudio. 


Capa "Pizarra" 


Capa Ontología 


Emergencias 


Expresión 41 


Capa expresión 


Fig. 4. Organización de la estructura en árbol de ontologías 


Los agentes móviles son priorizados en función de sus 
propiedades. Un agente móvil pertenece a uno o más dominios 
u ontologías. Sus propiedades se calcularán en función de 
las diferentes expresiones asociadas a las ontologías. Tene- 
mos dos posibilidades para calcular estas prioridades. Por un 
lado podríamos dejar que la plataforma local consultase las 
variables locales de todos los agentes móviles y calcular sus 
prioridades. Por otro lado, una segunda opción sería dejar que 
los agentes móviles calculasen sus propiedades ellos mismo e 
informasen de ella a la plataforma local antes de su migración. 

Se ha de tener en cuenta que en ambas opciones los agentes 
móviles podrían falsificar estas prioridades. En la primera 
opción, un agente móvil podría llegar a modificar sus variables 
locales para obtener una mayor prioridad de la que merece. 
En cambio, en la segunda opción, el agente móvil podría 
directamente declarar a la plataforma local una prioridad 
inmerecida. 

Las prioridades falsificadas no deberían afectar a otros 
agentes móviles de otros aplicaciones. Por lo tanto, los agentes 
móviles pertenecientes a diferentes aplicaciones no deberían 
competir directamente entre ellos. La propuesta es incluir en el 
planificador una estructura round robin que contenga una cola 
por aplicación. La plataforma recorre la estructura obteniendo 
el primero o los n primeros elementos de cada cola, en función 
del peso asignado a cada aplicación. Esta peso es determinado 
por la importancia cada aplicación y está controlado por la 
plataforma local. 

En la figura 5 cuatro colas que pertenecen a cuatro apli- 
caciones diferentes se definen. El planificador permite migrar 
en cada turno un número diferente de agentes móviles de las 
diferentes colas, siguiendo la estructura round robin. 
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Colal Cola 4 


Cola 2 


Cola 3 


Fig. 5. Estructura round robin con las colas de las aplicaciones 


B. Congestión DTN 


Un problema muy común en todo tipo de redes es el 
problema de la congestión. Las capas tradicionales de TCPAP 
intentan solventar el problema desde varias de sus capas. 
Por una lado TCP trata los problemas de extremo a extremo 
e intentar encontrar una velocidad óptima de comunicación, 
mientras que IP, que se ocupa de los nodos intermedios, 
maneja colas y políticas de descarte de datagramas cuando 
estas colas se saturan. 

En el caso de redes DTN, la congestión creada por flujos 
de datos con un ritmo elevado es un problema secundario, 
por la misma definición de red DTN. En la capa DTN nos 
enfrentamos a problemas similares a los de IP. Los agentes 
móviles que transportan bundles o bien la información de 
aplicación, permanecen acumulados en nodos DTN hasta que 
otro nodo DTN acepte su custodia. Si el buffer en el que 
los agentes móviles se acumulan se llena, tiene que haber 
un criterio para ver qué agente móvil debería ser descartado. 
Nuestra propuesta para llevarlo acabo es dinámica, permitimos 
que los mismos agentes móviles propaguen estos criterios. 

En la figura 6, se puede ver como un agente móvil transporta 
la información sobre la congestión de la plataforma en la que 
se halla. Esta plataforma se encuentra saturada de agentes 
móviles tal y como se ve en la representación de su cola. El 
agente móvil transporta esta información sobre la congestión a 
su plataforma destino de tal modo que futuros agentes móviles 
dispongan de esta información y elijan como plataforma 
destino plataformas alternativas a la plataforma congestionada. 


Nodo 
Custodio 


l==l 


*,Cola de agentes 
*. casi vacía 


Cola agentes casi llena 


Fig. 6. El agente móvil lleva información sobre la congestión de plataforma 
en plataforma 


La desventaja de este modo de controlar la congestión 
es que un agente móvil podría informar a una plataforma, 
de forma fraudulenta, sobre una inexistente congestión en 
una plataforma vecina. Consecuentemente, esta plataforma 
vecina sería ignorada por los algoritmos de encaminamiento, 
lo cual podría dar lugar a una denegación de servicio de esta 
plataforma o congestión de otras plataformas. 


C. Control de flujo 


Dentro del estándar del protocolo Bundle protocol existe la 
opción del control del flujo, que es una manera de orientar 
a niveles inferiores al bundle con el objetivo de obtener 
una determinada calidad de servicio. En el caso de que 
agentes móviles transporten bundles, el objetivo es definir una 
correspondencia entre la identificación del flujo en el bundle 
y las prioridades de los agentes móviles asociados con los 
bundles 

Por un lado tenemos la prioridad definida por el emisor de 
la aplicación incluida en la cabecera del bundle, tal y como se 
define en [19]. Esta prioridad es estática y no tendría sentido 
modificarla, pero puede ser tenida en consideración a la hora 
de calcular la prioridad del agente móvil asociado al bundle. 
Pero si lo que queremos es dar una cierta calidad de servicio 
a un cierto flujo de bundles, podremos usar el flow label 
definido en [19]. En nuestra implementación del planificador 
se ha incluido una manera de dar prioridades razonablemente 
parecidas a agentes móviles dentro del mismo flujo. 

Un agente móvil podría falsear el flujo al que pertenece 
con el fin de obtener una determinada calidad de servicio 
no merecida. Por tanto, se necesita definir mecanismos de 
seguridad que garanticen la autenticidad del identificador del 
flujo para evitar posibles falsificaciones de éste. 


D. Capacidad de los recursos de computación 


Todos los agentes móviles que corren en una plataforma 
comparten los mismos recursos de cálculo. El código de 
un agente puede consumir excesivamente los recursos de la 
plataforma como los ciclos de la cpu, la memoria o el ancho 
de banda, de tal modo que la plataforma se vea impedida de 
dar servicio a otros agentes móviles. Establecer límites tanto 
de memoria como de cpu para los agentes móviles es un tema 
delicado. Se podría limitar el buen funcionamiento de agentes 
no fraudulentos. 


E. Capacidad de almacenamiento dedicado a los agentes 


El tamaño de la colas de almacenamiento de agentes 
móviles es limitado. En el caso de que se llegue al límite de 
la cola, nuevos agentes móviles o incluso agentes encolados, 
tendrán que ser descartados. Esto es un manera muy fácil 
de provocar una denegación de servicio. Basta inundar una 
plataforma con agentes móviles, que la plataforma tendrá que 
descartar agentes móviles. Los agentes encolados descartados 
serán aquellos con prioridad más baja. Individuar a partir de 
los agentes móviles, cuáles son parte de la inundación es 
complicado, ya que no todos pueden venir del mismo origen 
ni puede que tengan ningún patrón en común. 
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E. Autenticación de las plataformas 


Por un lado, necesitamos tener la seguridad que las mi- 
graciones de los agentes móviles son secretas y autenticadas, 
además que se debe asegurar el no repudio de éstas. Por otro 
lado, se tiene que elegir si las plataformas pueden albergar 
cualquier agente móvil o debería ser un ambiente cerrado 
y autenticado. En el caso de las redes convencionales como 
internet, los routers se incorporan a las redes como un sistema 
abierto. Creemos que en ambientes DTN debería ser igual. Es 
evidente que esto comporta problemas de seguridad inevitables 
como plataformas que aceptan agentes móviles con el fin de 
provocar denegaciones de servicio o por tener acceso físico a 
éstas. 


IV. HACIA UNA ARQUITECTURA SEGURA EN REDES DTN 
BASADAS EN AGENTES MÓVILES 


Existe abundante literatura que propone soluciones para 
aplicaciones basadas en agentes móviles, como por ejemplo 
[21] o [24]. Tratan temas generales como seguridad en las 
plataformas, ejecución segura de agentes móviles, confiden- 
cialidad de los datos de los agentes, integridad del código del 
agente, transporte de llaves, confidencialidad en la comuni- 
cación entre agentes, etcétera. Las soluciones propuestas para 
muchos de los problemas se apoyan en procedimientos de 
seguridad clásicos, como puede ser sistemas asimétricos PKI 
basados en llave pública y llave privada. 

La falta de conectividad simultánea que se observa de 
manera generalizada en las redes DTN dificulta el uso de 
infraestructuras similares a PKI. Por ejemplo, en el caso de 
la comunicación entre agentes, al tratarse éste de un servicio 
proveído por las plataformas, una de las soluciones clásicas 
que se utilizan para garantizar están basadas en una PKI. Cada 
agente dispone de un certificado expedido por una autoridad 
certificadora (CA). Esto representaría un problema en caso de 
usarse sobre una DTN, ya que para poder cifrar la información 
o comprobar una firma se necesita tener acceso a las llaves 
públicas de las partes implicadas. Debido a la posible falta de 
conectividad, en ambientes DTN no se puede asumir el acceso 
a los servidores que proveen estas llaves, así como tampoco 
podemos garantizar disponer de listas actualizadas con los 
certificados revocados por las autoridades certificadoras (listas 
CRL's). 

La solución propuesta en [9] a este problema se basa en 
la criptografía basada en identidades (Identity based Cryp- 
tography). Las llaves públicas no se obtienen, sino que se 
generan a partir de cadenas identificadoras conocidas, como 
el propio nombre del agente o el nombre de la plataforma. 
Las llaves públicas son generadas por los PKG (Private Key 
Generator). Cada llave es válida por un cierto periodo, un 
día por ejemplo. Por tanto, con este tipo de sistema crip- 
tográfico las listas de revocación no son necesarias, ya que 
son sustituidas por una actualización de los identificadores. 
En el caso de los agentes móviles, estos identificadores 
podrían ser el nombre de la plataforma o el nombre del 
agente concatenado con el periodo de validez de la llave. 
Por ejemplo, agenteplatform.uab.cat-7-9-2010. 


Ésta será la llave pública con la que cualquier agente 
móvil podrá cifrar información con destino al agente móvil 
agentfplatform.uab.cat, o autenticarlo. Del mismo 
modo, se puede utilizar para comprobar la validez de firmas en 
general, con aplicaciones directas a muchos de los problemas 
de seguridad expuestos en la sección anterior. 

Sin embargo, la propia naturaleza de las redes DTN hacen 
que la IBC tampoco resulte una solución ideal. Los retrasos 
en la transmisión son tan importantes en algunas DTN que 
podrían contarse en días o meses. Este escenario complica, 
por ejemplo, la validación de la autenticidad de unidades de 
información que fueron firmadas con anterioridad al periodo 
actual de validez. 

Usar agentes móviles para implementar redes DTN tiene 
la ventaja añadida de poder usar las soluciones criptográficas 
diseñadas específicamente para ellos. Por ejemplo, la auto- 
protección de agentes [25], en la que el mecanismo de pro- 
tección del agente se encuentra en su propio código. De esta 
manera podría protegerse (privacidad, integridad, autenticidad, 
etc.) la unidad de transporte de información y la información 
intercambiada entre nodos sobre encaminamiento, por ejem- 
plo. La auto-protección de agentes permite además, la coex- 
istencia de mecanismos diferentes. Así, diversas aplicaciones 
con necesidades de seguridad diferentes podrían usar esquemas 
de protección independientes, sin tener que alterar los nodos 
de encaminamiento. 

Cuando no es posible utilizar ninguna de las soluciones de 
seguridad disponible, por cuestiones propias de la red o de 
la aplicación, siempre puede recurrirse a esquemas basados 
en modelos de confianza [26]. La reputación, por ejemplo, 
ganada por los nodos en un histórico reciente de interacciones 
podría usarse de manera combinada con un sistema dinámico 
de recomendaciones para valorar el riesgo de atentados contra 
la seguridad de las comunicaciones, o para aplicar técnicas de 
ostracismo a los nodos problemáticos. 


V. CONCLUSIONES Y TRABAJOS FUTUROS 


En este artículo se ha presentado una arquitectura DT'N 
basada en agentes móviles como alternativa no excluyente 
a la tradicional propuesta por el protocolo Bundle protocol. 
La aportación fundamental de la nueva arquitectura es la 
capacidad de los agentes de ejecutar código a la vez que trans- 
portan información de aplicación. Esta arquitectura incluye un 
planificador de agentes móviles con el fin de permitir a agentes 
considerados importantes poder migrar lo antes posible. Estas 
propuestas ayudarán a mejorar aspectos de las redes DT'N 
como el encaminamiento, la congestión, el control de flujo, 
la fiabilidad y a disminuir los retrasos, pero en cambio serán 
la principal fuente de problemas de seguridad. 

El objetivo es garantizar en todas las operaciones derivadas 
de nuestra arquitectura propuesta, la confidencialidad, la auten- 
ticación, la integridad y el no repudio. Mecanismos como los 
sistemas tradicionales PKI no son válidos por la intermitente 
falta de conexión. 

Como propuestas generales para resolver estos problemas 
de seguridad se plantean tres mecanismos. El primero fun- 
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damentado en la criptografía basada en identidades (Identity 
based Cryptography). Añadir el periodo de validez a las 
cadenas identificadoras conocidas permite prescindir de las 
listas de revocación, pero conllevan ciertas limitaciones. El 
tamaño de estas cadenas es extremadamente pequeño si lo 
comparamos con una llave PKI tradicional. Un ataque por 
fuerza bruta permitiría en un tiempo razonable obtener su 
correspondiente llave privada. Incluso si la validez de este par 
de llaves es de un tiempo determinado, como trabajo futuro 
se tendría que evaluar cómo gestionar comunicaciones que 
sean extremadamente perdurables, más allá de este tiempo de 
validez y sin permitir ataques de fuerza bruta. 

Sea cual sea la solución de seguridad escogida para una 
aplicación sobre DT'N cualquiera, la utilización de los agentes 
móviles como base de la arquitectura de la red añade la ventaja 
de poder utilizar de manera simultánea varios esquemas. Esto 
se consigue con el segundo mecanismo propuesto mediante 
técnicas de auto-protección. 

El tercer y último punto a mencionar son los modelos de 
confianza, que podrían usarse en casos extremos donde los 
agentes tengan dificultades para obtener información para el 
uso de esquemas de seguridad (como por ejemplo llaves). 
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Resumen—El rendimiento de las aplicaciones que utilizan el 
protocolo de transporte TCP (Transmission Control Protocol) 
sobre enlaces vía satélite tiene una degradación significativa. 
Esto se debe principalmente a que el algoritmo de control 
de congestión estándar de TCP no es adecuado para superar 
las deficiencias de las redes satelitales. TCP splitting es una 
solución prometedora para mejorar el rendimiento general de 
TCP, incluso en el segmento satelital. La división de la conexión 
TCP se logra mediante la instalación de dos PEPs (Performance 
Enhancement Proxies) en los extremos del segmento satelital. Sin 
embargo, la división de TCP entra en conflicto con IPsec. Si el 
cifrado y/o la autenticación son aplicados sobre los datagramas 
IP, el PEP no puede manipular las correspondientes cabeceras 
IP y TCP para dividir las conexiones TCP. En este trabajo 
presentamos tres propuestas para implementar IPsec en un 
escenario TCP splitting, proporcionando los servicios de seguridad 
habituales y un buen rendimiento en la conexión vía satélite. La 
idea básica es permitir a los PEPs manipular las cabeceras IP y 
TCP en función del nivel de confianza que los usuarios tengan 
en ellos. 


Il. INTRODUCCIÓN 


Las redes de banda ancha vía satélite están ganando impor- 
tancia debido a su alta disponibilidad de ancho de banda y 
gran cobertura. Estas redes satelitales jugarán un papel crucial 
en el futuro de Internet debido a la necesidad de servicios 
de comunicación en cualquier momento y en cualquier lugar. 
Sin embargo, se ha demostrado que el protocolo TCP (Trans- 
mission Control Protocol) tiene una degradación significativa 
sobre enlaces satelitales. Esto se debe principalmente al hecho 
de que las redes con enlaces satélite presentan grandes retardos 
de propagación, introducen una alta probabilidad de error de 
transmisión y disponen de un notable nivel de asimetría entre 
los anchos de banda de los canales de difusión y de retorno. 

La degradación de TCP se debe principalmente a que 
su algoritmo de control de congestión no es adecuado para 
superar las deficiencias de los enlaces satelitales [1], [2]. 
TCP aumenta su ventana de congestión hasta que se produce 
una pérdida. Entonces, cuando ésta es detectada, el número 
de paquetes dentro del sistema se reduce a la mitad. En 
las redes terrestres, las pérdidas de paquetes son causadas 
principalmente por la congestión en las colas de espera de 
los dispositivos de red. No obstante, las pérdidas de paquetes 
también pueden ser causadas por errores de transmisión. Este 
efecto es especialmente notable en las redes inalámbricas, 
provocando una reducción innecesaria de la carga del sistema 
y, por lo tanto, del rendimiento del protocolo TCP. Esta 
degradación se ve acentuada cuando la red inalámbrica además 
dispone de un elevado RTT (Round Trip Time). Así, en redes 


con satélites geoestacionarios, las conexiones TCP pueden 
tardar varias decenas de segundos en restituir la carga de 
paquetes tras una pérdida de paquetes debido a errores de 
transmisión. 

Se han propuesto algunas soluciones para superar los pro- 
blemas de TCP sobre enlaces satelitales [3]. Por un lado, 
algunas extensiones del TCP estándar han sido propuestas 
especialmente para las redes vía satélite. Y por otra parte, 
algunas variantes de TCP han sido especialmente diseñadas 
para optimizar su rendimiento en entornos satelitales, como 
TCP Peach, TCP Westwood o TCP Hybla. 

Sin embargo, la eficacia de estos dos tipos de soluciones 
está limitada por el hecho de que no están universalmente 
adoptadas por todos los sistemas finales en Internet. 


Forward/Return 
Channel 


Sender Host 


Internet 


4 PE OY 


q Standard 
TCP 


de Optimized TCP TCP 


-- 
Receiver Host 


Figura 1. 7CP splitting. 


Los PEPs (Performance Enhancement Proxies) pueden ser 
introducidos para utilizar esos protocolos optimizados, o ex- 
tensiones, sobre enlaces vía satélite, sin variar los TCPs de los 
segmentos cableados [4]. El objetivo es dividir la ruta completa 
en segmentos cableados y un segmento satelital. En general, la 
comunicación se divide en tres partes o conexiones: emisor- 
PEP, PEP-PEP y PEP-receptor. Este mecanismo también se 
conoce como TCP splitting. La figura 1 muestra un escenario 
típico de esta técnica, en la que un barco (que actúa como 
servidor) proporciona contenidos a un host situado en Internet. 

El objetivo de la división es aislar el enlace satelital de 
gran latencia mediante la introducción de agentes intermedios 
(PEPs), que dividen la conexión TCP. Los PEPs son responsa- 
bles de la recepción, el almacenamiento, y el reconocimiento 
de los datos generados por un emisor, y además, del reenvío de 
éstos hacia el receptor. TCP splitting permite implementar un 
control de congestión optimizado para mejorar el rendimiento 
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de TCP en la conexión vía satélite, y dejar el protocolo 
TCP estándar en los segmentos cableados. Esta división es 
transparente tanto para el origen como para el destino de la 
comunicación. 

Las redes satelitales también son propensas a ataques de 
seguridad, debido especialmente a su naturaleza broadcast. 
Por esta razón, es necesario proteger estas comunicaciones. 
IPsec es una solución estándar que proporciona los servicios de 
seguridad necesarios para prevenir la mayoría de estos ataques. 
A diferencia de otras soluciones extremo a extremo que operan 
en la capa de transporte o en la capa de aplicación, IPsec opera 
en la capa de red. IPsec se utiliza principalmente para crear 
VPNs (Virtual Private Networks), aunque también se puede 
utilizar para proteger las comunicaciones entre dos máquinas 
remotas. En nuestro escenario, el problema es que el uso de 
IPsec afecta negativamente al funcionamiento de los PEPs, ya 
que ellos necesitan manipular las cabeceras de los protocolos 
TCP/IP, que están criptográficamente protegidas. Si se utiliza 
IPsec, los PEPs no pueden dividir las conexiones TCP y, en 
consecuencia, el rendimiento de TCP en la redes satelitales no 
puede ser mejorado. 

En este trabajo presentamos tres propuestas diferentes para 
permitir que IPsec y TCP splitting puedan trabajar conjun- 
tamente. El objetivo es proporcionar a las comunicaciones 
los niveles de seguridad adecuados, sin afectar demasiado 
las operaciones realizadas por los PEPs. En la primera pro- 
puesta, que se explica en la sección II-A, consideramos un 
escenario particular en el que los usuarios finales (emisor y 
receptor) no confían en el operador satelital (tal vez porque 
desconocen su existencia), por lo que quieren que todos los 
datos intercambiados sean protegidos criptográficamente por 
IPsec. Así pues, no se confía en absoluto en los PEPs, y 
por ello no pueden ni leer ni manipular los paquetes TCP/1P, 
y obviamente, no pueden dividir las conexiones TCP. Sin 
embargo, estos paquetes son encapsulados por un protocolo 
TCP optimizado con el fin de mejorar el rendimiento en la 
conexión satelital. En las otras dos propuestas que se explican 
en las secciones IIMI-B y III-C, respectivamente, consideramos 
que los usuarios finales conocen al operador satelital y confían 
en él. Esto permitirá que los PEPs puedan leer/modificar todo 
el contenido (Fully-trusted PEPs), o ciertas partes (Partial- 
trusted PEPs), de los paquetes TCP/IP, dependiendo del grado 
de confianza que los usuarios puedan tener en el operador de 
red y la mejora de rendimiento que quieran conseguir. 


IT. TRABAJOS RELACIONADOS 


Las propuestas que utilizan IPsec en escenarios satelitales 
con PEPs se pueden clasificar en dos grupos, los que modifican 
el comportamiento estándar de IPsec y los que sólo se adaptan 
a él. 

En cuanto al primer grupo de propuestas, una de las 
soluciones más interesantes es ML-IPsec [5], que se basa en 
dividir los paquetes en diferentes zonas donde se aplicarán 
los diferentes servicios de seguridad de forma independiente. 
El número de zonas y su tamaño son definidos a priori 
utilizando un mapa de zonas. La propuesta también rediseña 


las Asociaciones de Seguridad (SAs) para definir el tipo de 
seguridad (algoritmos criptográficos, claves, etc.) que se va 
a utilizar en cada zona. Se crea una nueva Asociación de 
Seguridad Compuesta (CSA), que consta de dos partes: una 
que contiene información común a todas las zonas, y otra que 
contiene una lista de SAs reducidas, una por zona. Tanto el 
mapa de zonas como la CSA son compartidas por todos los 
dispositivos que tienen acceso a alguna zona de los paquetes 
IPsec. En [6] se puede encontrar un análisis crítico de ML- 
IPsec. [7] y [8] son dos propuestas que también dividen los 
paquetes en zonas: una zona para las cabeceras TCP/IP y otra 
para los datos de usuario. En [8], las dos zonas están cifradas 
con dos claves diferentes, mientras que en [7] también se 
utilizan diferentes algoritmos criptográficos. 

En referencia al segundo grupo de propuestas, en [9], los 
dispositivos IPsec establecen una sesión con el PEP para 
proporcionarle la información necesaria para generar los ACKs 
prematuros. El PEP utiliza un Identificador de Conexión (CI) 
para relacionar cada paquete TCP con la información propor- 
cionada por el remitente. Otras soluciones proponen generar un 
hash de la información de flujo TCP e incluirlo en el campo 
de opciones de la cabecera IP [10], [11]. En este caso, los 
PEPs pueden distinguir diferentes flujos de tráfico TCP sin 
necesidad de modificar los paquetes, por lo que es posible 
retransmitir los paquetes perdidos en el enlace satelital (TCP 
snooping). En [12], el mecanismo de recuperación de pérdidas 
de TCP está explícitamente informado sobre la naturaleza 
de las mismas. En [13], los temporizadores TCP se pueden 
congelar obligando al emisor TCP a pasar al modo persistente. 


MI. SOLUCIONES DE SEGURIDAD IPSEC EN 
ARQUITECTURAS TCP SPLITTING 


Como ya se ha comentado, nuestro objetivo es implemen- 
tar servicios de seguridad con IPsec en arquitecturas TCP 
splitting. El problema es que en estas arquitecturas los PEPs 
necesitan tener acceso a la información transportada por los 
paquetes en las cabeceras TCP/IP. Como veremos más ade- 
lante, existe un compromiso entre la mejora del rendimiento 
de la comunicación y la aplicación de la seguridad. También 
queremos mencionar que no hemos considerado las soluciones 
que se basan en no aplicar los servicios de seguridad a ciertas 
partes del paquete o en copiar algunos datos en áreas no 
protegidas por IPsec. No consideramos este tipo de soluciones 
porque crean críticas vulnerabilidades de la seguridad. En este 
caso, las comunicaciones seguras tienen lugar entre entidades 
de confianza, mientras que los dispositivos intermedios que no 
son de confianza no tendrán acceso a los datos transportados 
por los paquetes IPsec. 

En este trabajo, proponemos tres maneras de lograr se- 
guridad. La primera propuesta considera que los PEPs no 
son entidades de confianza. Por otra parte, la segunda y la 
tercera consideran que los nodos finales tienen cierto grado de 
confianza en los PEPs. Para estos dos casos, hemos desarrolla- 
do un sencillo protocolo de intercambio seguro para que los 
dispositivos IPsec compartan las Asociaciones de Seguridad 
(SAs) con los PEPs. 
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HPA. Untrusted PEPs 


En esta propuesta los PEPs no se consideran entidades de 
confianza. Esta consideración hace que no puedan manipular 
las cabeceras TCP/IP. Esto evitará que los PEPs puedan aplicar 
los mecanismos correspondientes para mejorar el rendimiento 
del enlace satelital, como el envío de confirmaciones prema- 
turas a los usuarios finales (7CP spoofing). Por esta razón, 
la única manera de mejorar el rendimiento sin revelar ningún 
dato sobre el paquete, es encapsularlos en un protocolo TCP 
optimizado. Con esta solución, los PEPs, al menos, pueden 
controlar las retransmisiones necesarias sobre el enlace sateli- 
tal. Más concretamente, este control de retransmisión lo llevan 
a cabo los PEPs mediante el intercambio de reconocimientos, 
teniendo la propiedad de gestionar las retransmisiones de 
paquetes debidas a pérdidas en el enlace satelital de forma 
transparente a los usuarios finales. Por lo tanto, se evitan 
los efectos de una reducción innecesaria de la carga en el 
sistema. Observe que esta propuesta se comportará como un 
mecanismo típico de snooping, pero manteniendo los paquetes 
IPsec sin cambios. 

El hecho de que el PEP deba establecer una conexión 
TCP optimizada antes de poder enviar información, hace que 
esta solución requiera del establecimiento de dos conexiones: 
una conexión TCP estándar entre los usuarios finales y otra 
conexión TCP optimizada entre los PEPs. El inconveniente 
es que para establecer conexiones, TCP utiliza un Three-Way 
Handshake que introduce cierto retardo, y por consiguiente, 
una reducción del tiempo de respuesta de la aplicación de 
usuario. En la figura 2 se muestra el intercambio de paquetes 
requeridos por esta propuesta. 


Sender PEP PEP Receiver 


Figura 2. Three-Way Handshake en la propuesta Untrusted PEPs. 


Los paquetes marcados con el “1” son los que se utilizan 
para establecer una conexión TCP estándar entre los usuarios 
finales. Por otra parte, los paquetes marcados con el “2” son los 
que se usan para establecer la conexión TCP optimizada. Un 
simple análisis permite observar que la fase de establecimiento 
de la conexión extremo a extremo se incrementa en un RTT del 
segmento satelital. Este incremento está dentro del margen de 
operación del protocolo TCP estándar que admite un tiempo 
de espera del primer paquete SYN de hasta 3 segundos. Una 


descripción detallada de la operación de los PEPs en esta 
propuesta sería la siguiente: 


1. El primer PEP extrae la cabecera IP de los paquetes 
que le llegan a la capa de red y los pasa a la capa de 
transporte. 

2. Una vez en la capa de transporte, el PEP añade la ca- 
becera del protocolo TCP optimizado y, a continuación, 
pasa los paquetes a la capa de red. 

3. La capa de red añade la cabecera IP y transmite los 
paquetes a través del enlace satelital. 

4. El otro PEP recibe los paquetes a través del enlace 
satelital, y una vez en la capa de red, les extrae la 
cabecera IP y los pasa a la capa de transporte. 

5. En la capa de transporte, el PEP genera un paquete ACK 
para cada paquete recibido. 

6. A continuación, el PEP elimina la cabecera del protocolo 
TCP optimizado y devuelve el paquete a la capa de red. 

7. Por último, la capa de red añade la cabecera IP y envía 
el paquete a su destino final. 


Hay que tener en cuenta que los pasos anteriores tienen 
que ser realizados para cada uno de los dos sentidos de 
la comunicación, y tanto para paquetes de datos como para 
paquetes ACK. 

Por otra parte, también notar que los paquetes permane- 
cen protegidos desde el inicio de la comunicación hasta el 
final mediante IPsec. Como resultado, en caso de utilizar 
el protocolo de seguridad Authentication Header (AH) se 
proporciona integridad de los datos y autenticación, y en 
caso de utilizar el Encapsulating Security Payload (ESP) la 
confidencialidad está asegurada. Por lo tanto, el nivel de 
seguridad de esta propuesta es equivalente al proporcionado 
por el IPsec estándar. 

Los dos principales inconvenientes de esta propuesta son: 


= El overhead introducido en los paquetes debido al hecho 
de añadir una nueva cabecera TCP en el enlace satelital. 

= Un aumento del retardo debido a la creación y al cierre 
de las conexiones TCP adicionales entre PEPs. 


La propuesta presentada en esta sección puede ser conve- 
niente para escenarios en los que los dispositivos IPsec finales 
no saben de antemano que sus comunicaciones van a pasar a 
través de un enlace vía satélite. En tal escenario, los usuarios 
pueden utilizar IPsec normalmente sin tener que tomar ninguna 
decisión adicional. Un ejemplo de este tipo de escenario puede 
ser un host ubicado en una red de área local (LAN) que no 
es consciente de que se está conectando a Internet a través de 
un enlace satelital. 


IIFB. Fully-trusted PEPs 


En esta propuesta se supone que uno de los usuarios finales 
que utiliza IPsec puede establecer una relación de confianza 
con uno de los PEPs. Este puede ser el caso de un usuario 
cuyo ISP (Internet Service Provider) es un operador satelital. 
Aquí suponemos que el usuario puede confiar completamente 
en los PEPs. Con este tipo de propuesta es posible poner 
a su disposición la información contenida en las cabeceras. 
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En este caso, el PEP podrá crear/modificar paquetes IPsec 
válidos, posibilidad que puede aprovecharse para mejorar el 
rendimiento de la conexión vía satélite. 

Entrando más en detalle, nuestra propuesta funciona de la 
siguiente forma. En un principio, los usuarios origen y destino 
establecen una conexión IPsec extremo a extremo mientras los 
PEP se encuentra en modo pasivo (no están involucrados en 
esta fase de la comunicación). Una vez que la comunicación 
IPsec está establecida, y por tanto las SAs se han negociado, 
uno de los usuarios finales (el que tiene una relación de 
confianza con los PEP) se las envía a los PEPs!. Después 
de eso, ya se pueden empezar a transferir datos. 

En la fase de transferencia de datos de la comunicación, los 
PEPs operan de la siguiente forma: 


1. El primer PEP extrae la cabecera IP de los paquetes que 
le llegan a la capa de red. 

2. Extrae la protección criptográfica de los paquetes antes 
de enviar los datos de usuario a la capa de transporte. 

3. Una vez en la capa de transporte, envía un TCP ACK 
al usuario origen por cada paquete TCP recibido. Ya 
que el PEP conoce las SAs, puede crear TCP ACKs 
válidos para todos los paquetes recibidos (cifrados y/o 
autenticados). De hecho, el PEP suplanta al destino final. 

4. El PEP genera nuevos segmentos usando los datos de 
usuario extraídos de los paquetes recibidos y los pasa a 
la capa de red. Sin embargo, estos segmentos son de un 
TCP optimizado para la conexión vía satélite. 

5. En la capa de red les añade la protección criptográfica 
correspondiente y la cabecera IP. En estos nuevos pa- 
quetes IP, la dirección IP de destino no cambia. 

6. El PEP transmite estos paquetes IP a través del enlace 
satelital. 

7. El otro PEP recibe los paquetes, les extrae la cabecera 
IP y la protección criptográfica, y obtiene los datos de 
usuario para enviarlos a la capa de transporte. 

8. Este segundo PEP le envía un TCP ACK al primero por 
cada paquete recibido. 

9. En la capa de transporte, el PEP genera segmentos TCP 
estándar con los datos de usuario. Estos segmentos se 
transmiten a la capa de red. 

10. La capa de red les añade las protección criptográfica co- 
rrespondiente y la cabecera IP. En estos nuevos paquetes 
IP, la dirección IP de destino no cambia. 

11. Por último, el PEP transmite los paquetes sobre el enlace 
terrestre. 


La solución propuesta es equivalente al típico TCP splitting 
excepto por el hecho de que tenemos una protección adicional 
en los paquetes IPsec de los usuarios. Tenga en cuenta que se 
establecen tres conexiones diferentes: emisor-PEP, PEP-PEP 
y PEP-receptor. En cada una de estas conexiones, se puede 
utilizar el TCP más adecuado. Por ejemplo, un TCP estándar 
para las conexiones terrestres y un TCP optimizado para la 
conexión vía satélite. 


l Observe que estas SAs se han de volver a enviar a los PEPs siempre que 
se hayan renegociado. 


La figura 3 muestra el Three-Way Handshake que se realiza 
para establecer estas conexiones. Como se puede observar, 
el tiempo requerido para establecer la conexión extremo a 
extremo en esta propuesta es prácticamente el mínimo posible 
sobre que queda determinado por el retardo de propagación 
del enlace satelital. 


PEP 


Sender Receiver 


Figura 3. Three-Way Handshake en la propuesta Fully-trusted PEPs. 


En resumen, esta propuesta mejora el rendimiento extremo 
a extremo porque, por un lado, el PEP puede enviar ACKs 
prematuros al emisor TCP (evitando reducciones innecesarias 
de la ventana de congestión), y por otro lado, el PEP puede 
utilizar un TCP optimizado para la transmisión sobre el enlace 
satelital. Además, la solución es completamente transparente 
para el usuario que no es cliente del operador satelital. 

Esta propuesta también tiene algunos inconvenientes. Los 
más importantes son los siguientes: 

= Una vez que los PEPs tienen las correspondientes SAs, 

pueden acceder a toda la información transmitida en los 
paquetes IPsec (incluyendo los datos de usuario). 

= Los PEPs tienen que manipular la protección criptográfi- 

ca correspondiente (por ejemplo, descifrar cada paquete 
recibido y cifrarlo antes de transmitirlo). 

Los inconvenientes anteriores implican que los PEPs ahora 
son considerados como terceras partes de confianza (es decir, 
son nuevos puntos de vulnerabilidad) y que se produce un 
aumento de la carga de procesamiento en ellos. 


1I-C.  Partially-trusted PEPs (2L-IPsec) 


Se propone una tercera propuesta que ofrece un buen 
equilibrio entre seguridad y rendimiento. Modifica el protocolo 
IPsec con el fin de proporcionar una protección criptográfica 
extremo a extremo de los datos de usuario, pero permitiendo 
que los PEPs puedan manipular las cabeceras TCP/IP para 
mejorar el rendimiento de la conexión satelital. Se supone que 
uno de los usuarios de IPsec tienen una relación de confianza 
con los PEPs. Al igual que en el caso anterior, este puede ser el 
caso de un usuario cuyo ISP (Internet Service Provider) es un 
operador satelital. Sin embargo, a diferencia del caso anterior, 
es suficiente una relación de confianza más débil entre los 
usuarios y los PEPs, ya que el PEP no manipula los datos de 
usuario, sólo las cabeceras TCP/IP. 

Nuestra propuesta se basa parcialmente en las propuestas 
ML-IPsec [5], LES [7] y [8], ya que también dividen los 
paquetes en diferentes zonas. Sin embargo, estas partes co- 
rresponden a diferentes capas en lugar de a distintas zonas. 
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La idea es usar capas de cifrado, ya que nos permite divulgar 
selectivamente diferentes partes de un paquete a los distintos 
usuarios sin poner en peligro la seguridad de las otras partes. 
En nuestra propuesta, llamada 2L-IPsec (two-layer IPsec), una 
clave se utiliza para cifrar las cabeceras TCP/IP y otra para 
cifrar los datos de usuario. Los usuarios finales distribuirán 
la primera clave para que los PEPs puedan manipular las 
cabeceras TCP/IP y mantendrán en secreto la segunda, por 
lo que los PEPs no serán capaces de romper la protección 
criptográfica de los datos de usuario. 

En primer lugar, los usuarios finales de IPsec deben negociar 
la Asociación de Seguridad (SAs), mediante el protocolo 
estándar Internet Key Exchange (IKEv2) que proporciona 
IPsec, mientras los PEPs permanecen en modo pasivo. Estas 
SAs contendrán la clave criptográfica Iíp, que se utilizará para 
proteger los datos de usuario. Una vez que tengan las SAs, 
tienen que generar una nueva clave de cifrado para proteger 
las cabeceras TCP/IP, K' y, y enviársela a los PEPs?. 

Entonces, los usuarios finales tienen acceso a los paquetes 
enteros, y los PEPs sólo pueden manipular las cabeceras 
TCP/IP y no los datos de usuario. Esto es suficiente para 
aplicar las técnicas de splitting. 

En la fase de transferencia de datos de la comunicación, los 
PEPs operan de la siguiente forma: 


1. El primer PEP extrae la cabecera IP de los paquetes que 
le llegan a la capa de red. 

2. Extrae la protección criptográfica de las cabeceras 
TCP/IP, y envía los datos de usuario (que son protegidos 
criptográficamente usando Kp) a la capa de transporte. 

3. También envía un TCP ACK al usuario origen por cada 
paquete TCP que recibe. Ya que el PEP conoce Kg, 
puede crear ACKs criptográficamente protegidos. 

4. En la capa de transporte, el PEP genera nuevos seg- 
mentos usando los datos de usuario (protegidos), pero 
utilizando un TCP optimizado para la conexión vía 
satélite. Estos nuevos segmentos se transmiten a la capa 
de red. 

5. La capa de red les añade la protección criptográfica 
correspondiente y la cabecera IP (usando K' y). En estos 
nuevos paquetes IP, la dirección IP de destino no cambia. 

6. El PEP transmite los paquetes IP sobre el enlace satélite. 

7. El otro PEP recibe los paquetes, extrae la cabecera IP y 
la protección criptográfica (utilizando H¿), y obtienen 
los datos de usuario (protegidos) para enviarlos a la capa 
de transporte. 

8. En la capa de transporte, envía un TCP ACK al primer 
PEP por cada paquete que recibe. 

9. Genera segmentos TCP estándar con los datos de usuario 
(protegidos). Después los transmite a la capa de red. 

10. La capa de red les añade la protección criptográfica 
correspondiente y la cabecera IP, usando K' yy. En estos 
nuevos paquetes IP, la dirección IP de destino no cambia. 

11. Por último, el PEP transmite los paquetes sobre el enlace 


?Tgual que en el caso anterior, esta operación se debe repetir cada vez que 
las SAs sean renegociadas. 


terrestre. 


Observe que en el caso de que un paquete se pierda en 
cualquiera de las tres partes de la ruta, el paquete sólo se 
retransmitirá en dicha parte. Por otro lado, la definición de las 
zonas ha sido específicamente diseñada teniendo en cuenta que 
para aplicar TCP splitting el PEP sólo necesita acceso a las 
cabeceras TCP/IP. Por otra parte, el tamaño de estas cabeceras 
es variable, ya que pueden incluir información opcional. Así, 
hemos definido una zona que contiene las cabeceras TCP/IP 
y otra zona que cubre el payload de TCP, ambas de longitud 
variable. De esta manera, los PEPs siempre tienen acceso a la 
zona deseada sin importar el tamaño de las cabeceras, ya que 
su tamaño se gestiona de forma dinámica. 

La figura 4 muestra el formato de las cabeceras IPsec (AH 
y ESP) en los paquetes de 2L-IPsec (en modo de transporte). 
La longitud de las cabeceras, el offset a la siguiente cabecera y 
el tipo de protocolo de transporte encapsulado en el datagrama 
IP se determinan mediante cálculos matemáticos simples. 
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Padding (0-255 bytes) 


Authentication Data for Zone 2 
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Authentication Data for Zone 2 
(variable length) 


ESP Packet 


Figura 4. Formato de los paquetes 2L-IPsec (en modo transporte). 


Algunas de las ventajas de utilizar 2L-IPsec se resumen a 
continuación: 


= No compromete la seguridad de los datos de usuario. 
Esta propuesta preserva la seguridad de los datos de usua- 
rio entre los dispositivos 2L-IPsec. También proporciona 
confidencialidad, integridad y autenticidad del origen de 
los datos. 

= Seguridad reforzada de los paquetes. Ahora se tienen 
que romper dos claves diferentes para acceder a todos 
los datos contenidos en el paquete. 

= Preservar la confidencialidad extremo a extremo. Por 
ejemplo, si un PEP no necesita modificar ningún dato 
de los paquetes, entonces las SAs únicamente tendrán 
que incluir la clave de autenticación, pero no la clave de 
cifrado, para la zona correspondiente. 

= Son posibles las comunicaciones seguras utilizando TCP 
splitting. Este es uno de nuestros principales objetivos. 
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Tenga en cuenta que con esta propuesta podemos imple- 
mentar un mecanismo que controle qué partes específicas 
del paquete pueden ser leídas, modificadas, etc. por terce- 
ras partes involucradas en la comunicación. Además, nos 
permite generar los paquetes ACK prematuros requeridos 
por TCP splitting. Por último, también se pueden retrans- 
mitir los paquetes perdidos de manera independiente en 
cada parte de la ruta. 


Como se indica en [7], se ha demostrado que el rendimiento 
del cifrado de seguridad por capas es comparable al de IPsec. 

Nuestra propuesta también tiene algunas desventajas que 
deben ser consideradas, así: 


= 2L-IPsec no es una solución estándar. La mayoría de 
los dispositivos conectados a Internet no tendrán este 
nuevo protocolo. Esto limitará su uso a determinados 
escenarios, en los que es posible su implantación. Por 
ejemplo, un escenario real podría ser la comunicación 
de dos sedes de la misma empresa que utiliza un enlace 
vía satélite para sus comunicaciones. En este caso, los 
routers de las sedes son los usuarios IPsec finales. 
Estos dispositivos son los que podrían tener instalado el 
protocolo 2L-IPsec para mejorar el rendimiento de dichas 
comunicaciones. 

= Overhead. Nuestra propuesta aumenta el tamaño de los 
paquetes, cosa que afecta negativamente al rendimiento. 
Además, 2L-IPsec requiere más operaciones de cifra- 
do/descifrado, así que son necesarias más CPU y más 
memoria. Sin embargo, añadir seguridad siempre signi- 
fica que hay que añadir algo de sobrecarga al sistema. 

= Complejidad. Los usuarios finales deben descifrar y cifrar 
los paquetes en dos zonas diferentes utilizando dos claves 
en vez de una. 

= Distribución de las claves. Las claves tienen que distri- 
buirse a los PEPs de forma segura. 

= Generación de nuevas claves. Los usuarios finales tienen 
que generar claves adicionales. Una solución bastante 
simple podría ser el uso de funciones hash sobre la clave 
negociada, Hp, es decir, Ky =h(Kp). 


IV. CONCLUSIONES 


En este trabajo hemos analizado y propuesto soluciones para 
utilizar dos mecanismos que al ser aplicados conjuntamente 
provocan un conflicto. Estos mecanismos son la seguridad 
de red extremo a extremo proporcionada por IPsec y la 
optimización del rendimiento de las redes satelitales mediante 
TCP splitting. Por una parte la seguridad extremo a extre- 
mo normalmente utiliza criptografía en la capa de red para 
proteger los datagramas de usuario, y por otra TCP splitting 
requiere que los nodos intermedios puedan realizar operacio- 
nes “inteligentes” sobre los paquetes TCP para mejorar el 
rendimiento. El problema es que algunas partes de los paquetes 
que son necesarias para lograr las mejoras de rendimiento 
podrían no ser accesibles debido a la protección aplicada por 
IPsec. 

En general, la situación anterior es un problema difícil de 
tratar y hay que asumir que no existe una solución adecuada 


para todos los escenarios. En este sentido, lo mejor que pode- 
mos hacer es encontrar un conjunto de soluciones que ofrezcan 
diferentes compromisos entre seguridad y rendimiento. 

En este trabajo, hemos analizado las que consideramos las 
tres principales propuestas para solucionar el problema. Estos 
planteamientos conducen a tres ventajas y desventajas diferen- 
tes, que se han discutido a lo largo del trabajo. Por último, las 
diferentes propuestas también se pueden relacionar con varios 
escenarios posibles, también descritos en el documento. 
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Abstract—El presente artículo analiza las posibilidades de la 
distribución de estegotextos en redes sociales mediante los últimos 
avances desarrollados en esteganografía lingiística en lengua 
española. Existen muchas limitaciones a considerar si se desea 
ocultar información en textos en lenguaje natural de manera 
no trivial. En la práctica, la decisión de un procedimiento de 
ocultación u otro condicionará, desde un punto de vista práctico, 
el canal (en este caso red social) donde será más fácil transmitir 
una información oculta; esta característica podría facilitar el 
trabajo a un potencial estegoanalista. A modo de ejemplo, se 
analizan algunas características de la red social Twitter. 


Il. CONCEPTOS PREVIOS. ESTEGANOGRAFÍA 
LINGUÍSTICA 


La ciencia de la esteganografía puede ser definida como 
la ciencia y el arte de ocultar una información dentro de 
otra que haría la función de tapadera [1], con la intención 
que la existencia de dicha información no sea percibida. En 
teoría, sólo quienes conozcan cierta información acerca de esa 
ocultación (un secreto) estarían en condiciones de descubrirla. 
Cuando la cubierta es un texto en lenguaje natural ello implica 
un tipo específico de esteganografía, esteganografía lingúística, 
y el texto que oculta dicha información es llamado estegotexto. 

La idea de ocultar información en textos en lenguaje natural 
no es ni mucho menos nueva. En los últimos siglos diferentes 
procedimientos clasificables en open codes (cues, null ciphers, 
jargon code y grilles) y semagrams han sido documentados [2]. 
Algunos ejemplos famosos son newspaper code en la época 
victoriana o la verja de cardano en el siglo XVI [3]. 

En la actualidad, la esteganografía lingúística intenta aunar 
los principios de la ciencia de la esteganografía y la lingúística 
computacional (análisis automático del contenido textual, el 
análisis morfosintáctico, generación textual, la lexicografía 
computacional, descripciones ontológicas, etc.) para crear pro- 
cedimientos no triviales no basados en la oscuridad. En ese 
esfuerzo dos amplias líneas de investigación son abordadas 
[4]: a) la modificación de textos existentes y b) la generación 
automática de estegotextos. 


ll. ESTEGANOGRAFÍA EN REDES SOCIALES. 
ANTECEDENTES 


En 2008 [5] generalizando el uso de la aplicación de la 
herramienta de estegoanálisis StegSecret [6] a Internet, se 
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analizó el potencial de las características de las redes sociales 
con fines esteganográficos. En este trabajo [5] se analizó en 
primer caso los procedimientos esteganográficos más útiles 
para los estegomedios más probables en estas redes, como 
son el contenido multimedia (imagen, audio, video) y las 
tecnologías web (html, xml, http). Del mismo modo, se analizó 
la dificultad por parte de un atacante de acceder a posibles 
datos esteganografiados si éstos aprovechaban al máximo 
los mecanismos antibot/captchas y los grupos cerrados de 
usuario para evitar herramientas automatizadas de detección, 
así como se destacó la utilidad de distribuir contenido de 
forma multiportador y multiproveedor para evitar análisis por 
parte de proveedores con otros fines que los redactados en sus 
políticas de privacidad. 

Es en este contexto donde se decidió profundizar en el 
potencial de la ocultación de información en lenguaje natural 
de manera no trivial. La información textual está en todas 
partes, de forma masiva y con características lingiísticas muy 
diversas, esto la convierte en lo suficientemente interesante de 
manera individual y en su distribución en las nuevas redes 
sociales. 


HI. POTENCIAL DE LA ESTEGANOGRAFÍA 
LINGUISTICA EN ESPAÑOL 


En los últimos 5 años las publicaciones sobre esteganografía 
lingúística en lenguas tan diversas como el inglés, ruso o 
mandarín van en aumento, con utilidad en la ocultación de 
información en texto en lenguaje natural y con utilidad en 
el marcado digital de textos. Por desgracia, las publicaciones 
en lengua española son escasas. Debido a su potencial, en el 
último año y medio hemos realizado un esfuerzo en acotar 
la utilidad de diferentes procedimientos con aplicación en 
esteganografía lingiística en español. 

La utilización del lenguaje natural con fines 
esteganográficos de manera segura, considerando criterios 
lingúísticos (léxicos, sintácticos, semánticos, de cohesión, 
de coherencia, etc.) y esteganográfico-estadísticos (análisis 
de entropía, análisis de frecuencia de caracteres-palabras, 
ataques basados en conocimiento de cubierta original y 
cubierta modificada, etc), no es nada sencillo. 

La modificación de textos a menudo suele introducir errores 
detectables por un lector humano. Este inconveniente inicial 
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se convierte de utilidad para el productor de estos estegotextos 
ya que permite cuantificar en una primera instancia cómo 
de bueno es un procedimiento esteganográfico concreto de 
manera sencilla. La detección de anomalías por parte de un 
lector humano puede que sea mayor a las detectadas por 
algoritmos clasificadores automáticos. 

En la práctica, el lenguaje natural, como estegomedio, es 
muy poco redundante (ruidoso) en comparación con otros 
estegomedios como son las imágenes o los videos, lo cual 
hace más complicado la creación de algoritmos robustos de 
ocultación de información en lenguaje natural (información 
textual). Esta condición hace que las técnicas de ocultación 
requieran una gran cantidad de información textual para 
ocultar una cantidad de información no muy abultada. Este 
hecho puede hacer que estas técnicas sólo sean interesantes en 
escenarios limitados. Por ejemplo, en Internet ciertos canales 
serían más aptos para ocultar información que otros. 

En el objetivo de analizar qué técnicas esteganográficas en 
lenguaje natural para lengua española son más interesantes 
de detectar se analizaron los siguientes procedimientos 
englobados en las siguientes dos grandes líneas de 
investigación. 


a) Generación automática de estegotextos. 


Una buena alternativa para la ocultación de información 
en textos en lenguaje natural en español sería la generación 
automática de estegotextos. Su ventaja fundamental reside 
en la posibilidad de crear estegotextos únicos para cada 
comunicación, de forma que se dificulte ataques estadísticos y 
ataques basados en comparaciones texto original-estegotexto, 
así como tener un mayor control en la modelización estadística 
del estegotexto creado. 

En la última década los esfuerzos en este sentido se centran, 
principalmente, en la generación de estegotextos que imiten 
la gramática (sintaxis) y la estadística de un texto típico en 
una lengua concreta. Aunque, entre las opciones interesantes 
detectadas, se pueden establecer propuestas de generación 
automática de estegotextos basadas en construcciones CFGs 
(Context-Free-Grammar), derivadas de los principios de la 
teoría de la gramática generativa propuesta por el lingiística 
A.Noam Chomsky en la década de los 60, en primera instancia 
no se abordan estos estudios dado que tienen numerosas 
limitaciones a sortear, como se analizó en [7], por ejemplo, 
el problema de la privacidad/compartición/generación de la 
gramática utilizada, ataques basados en estudio de terminales 
(información última de cada regla), limitación del contexto de 
utilización y léxico utilizado, etc. 

En su lugar es más productivo en primera aproximación 
el uso de propuestas basadas en modelos estadísticos para 
minimizar en mejor medida ataques estadísticos a propuestas 
de esteganografía lingiiística. 

Con estas características es interesante el uso de un modelo 
estadístico N-GRAM con fines esteganográficos. Es decir, 
dado uno o más textos de entrenamiento es posible anotar 
las co-ocurrencias de las palabras presentes y medir las fre- 


cuencias de repetición de cada una (modelo N-GRAM), es 
decir, se anota qué palabra viene detrás de otra y con qué 
probabilidad. El algoritmo de generación de estegotextos elige 
en cada ocasión una de las palabras disponibles en función de 
la información a ocultar. Si la selección es aleatoria es más 
probable que salgan las palabras más probables que las que 
son menos, y por tanto se imite la estadística de la fuente 
de entrenamiento. Si se imita la estadística de la fuente es 
más probable que el estegotexto resultante que está basado en 
los textos de entrenamiento, tenga validez léxica y sintáctica 
(validez léxica y sintáctica que deben tener los textos de 
entrenamiento). Imitar el orden de las palabras tiene utilidad 
esteganográfica y como demostró Greenberg [8] el orden de las 
palabras determina hasta tal punto la hechura de una lengua, 
tanto que no admite trivialidades en su manipulación. 


Car Frec Código 


Tabla Raiz Car Frecuencia Código ea] 3 0 
La [habitación] 2 | 0 |o-» 
habi 7 10 nadie| 2 1 
itació había 
habitación [| DN N-ésimo Orden 
estaba limpió 11 
muy MM 2nd Orden a 
i DT Arbol Huffman 
sucia 
nodo 2nd orden 
ler Orden 
Fig. 1. Algoritmo de generación automática de estegotextos basado en 


modelo N-GRAM 


Esta posibilidad se comprobó en lengua española mediante 
la implementación de la herramienta Stelin [7]. Aunque de- 
pende del texto de entrenamiento, para órdenes de n mayor 
de 7 y textos de referencia mayores de decenas de KB se 
obtiene textos con validez léxica y gramatical. El tamaño final 
de estegotexto generado dependerá de la información a ocultar, 
de los textos de entrenamiento y del orden n. La capacidad 
mínima de información podría aproximarse entre 0,5 a 1 bit 
de información oculta por palabra generada. No obstante, este 
tipo de algoritmos todavía podrían generar estegotextos con 
errores gramaticales (depende en mayor medida del texto de 
entrenamiento). Estos errores podrían minimizarse basándose 
en los principios de la ley de Zipf (pocas palabras se repiten 
muchas veces) y en la idea que es posible añadir palabras a 
medida entre las palabras añadidas en la generación automática 
de estegotextos sin la necesidad que el receptor las conozca de 
manera adicional [9]. Por ejemplo, en la Figl, si el estegotexto 
creado fuera La habitación sería posible añadir palabras entre 
medias no incluidas en el nivel de la palabra habitación (añadir 
una O más palabras diferentes a había y limpió). De nuestra 
experiencia se observa que es posible conseguir estegotextos 
que oculten menos de 1.000 bits para una relación tiempo- 
esfuerzo razonable (si se usa edición manual) con una calidad 
lingúística elevada, que podría dificultar incluso la detección a 
lectores humanos. Este procedimiento sería de enorme utilidad 
para la distribución de claves criptográficas, urls, mensajes 
breves, coordenadas gps, etc. El tamaño del texto resultante 
dependería de la capacidad editora del emisor, del orden n y 
de los textos de entrenamiento. 

Siguiendo esta idea todavía sería posible dotar al emisor 
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de mayor libertad en la creación de estegotextos, creando 
automáticamente estegotextos de peor calidad pero con mayor 
facilidad de edición (herramienta ryfle) [10]. Un ejemplo de 
ello consistiría en dividir un texto fuente en grupos de palabras 
de tamaño W y basar la ocultación en la selección de una de 
cada grupo (por ejemplo asignamos el mismo peso a cada 
palabra). Así por ejemplo si la información a ocultar (en 
bits) fuera I, el número de palabras generadas sería Nmin 
y el tamaño mínimo necesario (en palabras) de la fuente de 
entrenamiento sería SOUrCemin : 


Nmin = I/logaW 
Sourcemin = Ninin * 2log2W 


Los estegotextos generados no tendrían validez (ni siquiera 
gramatical), pero para tamaños de grupo (W=4, 8 ó 16) [10] 
sería fácil añadir palabras antes de cada palabra seleccionada 
y que no estuvieran contenidas en cada grupo. Esta sencilla 
idea, el algoritmo es público, proporcionaría una alta calidad 
lingúística dificultando la tarea de detección a un lector 
humano (y por tanto a un algoritmo automatizado), si bien a 
un mayor coste de tiempo-esfuerzo por parte del emisor. Hoy 
día, se analizan variantes basadas en categorías lingiísticas y 
co-ocurrencias para facilitar y disminuir el tiempo necesitado 
en la edición manual [10]. 

Un procedimiento de este tipo sería ideal para la distribución 
de una manera altamente segura de claves criptográficas o urls 
(128-256 bits). Aunque el tamaño del estegotexto resultante 
dependería de la capacidad editora del emisor, este valor 
podría aproximarse a 3 ó 4 veces más que el tamaño Nmin, 
es decir, lo que supondría añadir de 3 a 4 palabras más 
por palabra generada (con 3 palabras se puede construir en 
español una oración básica: nombre+verbo+complemento). 
En [10] se adjunta un ejemplo de estegotexto de 281 palabras, 
0,44bits/palabra, que oculta 126 bits de información oculta. 


b) Modificación de textos existentes. 


La modificación de textos con utilidad esteganográfica con 
ciertos criterios de seguridad limita su actuación a una serie 
de procedimientos de ocultación relacionado con el léxico y 
la semántica, la gramática y la co-ocurrencia (orden de las 
palabras). Algunas de las propuestas más interesantes que 
se han documentado son [4]: sustituciones léxico-semánticas, 
sustituciones sintácticas, aprovechar el ruido de traducir un 
texto a diferentes idiomas, ocultación basada en formato 
y errores tipográficos/ortográficos (abreviaturas, acrónimos y 
otros). En este contexto se analizó las técnicas que parecen 
ser más productivas en otros idiomas, como por ejemplo los 
procedimientos en lengua inglesa. 

En primer lugar es interesante analizar el potencial de 
utilizar el orden de las palabras dentro de una frase con utilidad 
esteganográfica. En [11] se analizó, investigación que sigue en 
curso, el potencial de las modificaciones sintácticas en lengua 
española con utilidad esteganográfica y utilidad en natural lan- 
guage watermarking. Basándonos en mediciones en el corpus 
LEXESP [11] se demuestra cómo en español estructuras, con 


utilidad en otras lenguas como el inglés, como es la transfor- 
mación activa-pasiva no tiene utilidad esteganográfica, al no 
ser la pasiva una estructura lingúística frecuente en español. 
Este trabajo [11] analiza además la posibilidad de mover cier- 
tos elementos etiquetados previamente (Part of Speech) en una 
oración. De esta forma a nivel de frase, los resultados indican 
mayor utilidad esteganográfica en el movimiento de adverbios, 
especialmente si éste se sitúa al principio o final de frase, y el 
movimiento de adjetivos con respecto al nombre que modifica 
(anteponiéndolo o posponiéndolo), más concretamente 1.537 
parejas (nombre+adj o ad¡+nombre) muestran la posibilidad de 
mover el adjetivo delante o detrás de un nombre y por tanto 
de ocultar un bit por pareja. 

Aunque de momento estas investigaciones están en curso, 
en media (con suerte) 1 ó 2 bits por frase podrían ser ocultados 
mediante estos procedimientos. Si bien se podrían generar 
estegotextos indistinguibles de textos originales, es cierto que 
sería necesario una cantidad razonable de texto para ocultar 
información, por ejemplo, 128 frases para 128 bits (entiéndase 
que un texto podría ser fragmentado en frases considerando 
puntos, partículas que subordinen oraciones, etc.). 

Por otro lado, la ocultación basada en modificaciones léxico- 
semánticas sería posible. En [12] se analizó la posibilidad 
de ocultar información mediante la implementación de una 
herramienta avanzada de sustitución de sinónimos (23.918 
sinónimos únicos y soporte para variantes verbales, de género 
y número). Considerando procedimientos estadísticos para 
disminuir el impacto de una sustitución de una palabra en 
el contexto cercano de palabras vecinas se pueden realizar 
diferentes aproximaciones, basadas en reglas de Word Sense 
Disambiguation. Entre las propuestas documentadas en [12] 
una puede basarse en la construcción de tablas estadísticas 
que alimenten una función de ponderación que cuantifique 
cómo de bueno es un sinónimo para sustituirlo en un contexto 
dado. Siguiendo esta idea se podría conseguir una capacidad 
de ocultación próxima al 29,71% de las palabras totales de un 
texto. La ocultación mínima en esta situación considerando 1 
bit por palabra útil, sería en media de 0,2971 bits/palabra. No 
obstante, aunque se construya un tabla estadística significativa, 
nuestros experimentos están basados en un corpus de 120 
millones de palabras, y sólo se realizarán modificaciones 
considerando los dos sinónimos más probables de cada palabra 
a sustituir, en función de su contexto, todavía sería posible im- 
plementar un ataque haciendo uso de un clasificador SVM que 
detectara al menos el 50% de los documentos con información 
oculta, documentos de 269 palabras y 52,45 bits/documento. 


IV. ESTEGANOGRAFÍA LINGUISTICA EN REDES 
SOCIALES. MITOS Y REALIDADES 


La distribución de información oculta en textos en lenguaje 
natural mediante procedimientos no basados en oscuridad 
hace que las opciones disponibles para ocultar información se 
vean seriamente reducidas. En la práctica estos procedimientos 
estarán basados en sustituciones léxico-semánticas, uso del 
orden de las palabras (modelos estadísticos) y el posible uso 
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de reglas gramaticales. Desde un punto de vista aproximativo 
y puramente conceptual procedimientos de ocultación de este 
tipo daría una capacidad mínima de ocultación del orden 
expresado en la siguiente figura. 


Capacidad  |Procedimiento 
0,5 - 1 bit / 
palabra 
0,44 bits / 
palabra 


Técnica 


Modelo N-Gram 
(sin edición manual) 


Herramienta Ryfle 


Sustitución de palabras 
por sinónimos (uso 
tablas estadísticas) 


0,2971 bits / Ss 


| 
palabra 


Fig. 2. Capacidad mínima de ocultación por palabra del estegotexto creado 
o modificado. 


Modificaciones 
sintácticas basadas en el 
movimiento de palabras 


Según estos valores, e independientemente de la seguridad 
de cada técnica concreta, para ocultar, por ejemplo, una 
mínima información útil, que podría ser de unos 128 bits, se 
necesitaría fragmentos de textos de al menos: 128-256 palabras 
(N-Gram), 290 palabras (ryfle) y 430 palabras (sinónimos). 
Esta capacidad de ocultación implica la necesidad de textos 
de cierto tamaño. Por ejemplo, en su aproximación a las redes 
sociales todas estas técnicas son ideales en la publicación de 
estegotextos en blogs, más cuestionable puede ser (sin ser 
troceados o distribuidos) en comentarios en foros, mensajes 
en redes tipo facebook, tuenti y similares. 

Obtener los tamaños medios de los mensajes en este tipo de 
redes no es sencillo, al estar los usuarios en grupos cerrados, 
ya que el acceso implicaría anular sistemas de protección o 
autenticación. En cualquier caso y de forma aproximativa, el 
tamaño de los comentarios en facebook o tuenti se encuentra 
entre las 10 y las 25 palabras, excepciones puntuales (en los 
casos manualmente comprobados) excederían hasta no más de 
100 palabras. 

En el caso que se utilicen otros procedimientos, basados en 
técnicas sin documentar/publicar, la modelación del lenguaje, 
el uso de la estadística y el uso de expresiones lingilísticas 
podría facilitar la automatización del estegoanálisis de estas 
técnicas no documentadas. En este sentido, dado que existe un 
número importante de redes sociales donde el tamaño de la in- 
formación textual no permitiría (de forma simple) las técnicas 
documentadas (para ocultar al menos cientos de bits) podría 
ser interesante explotar nuevas características de ocultación. 
Por ejemplo, son interesantes las redes sociales basadas en 
comunicaciones rápidas, frases cortas, con poca preocupación 
en la calidad lingúística, produciéndose faltas ortográficas y 
tipográficas en cuantía. Un entorno donde podría ser intere- 
sante el uso de procedimientos esteganográficos basados en 
errores ortográficos y tipográficos sería precisamente este tipo 
de redes sociales donde el lenguaje no está muy cuidado. Dado 
que la presencia de faltas de ortografía podría hacer a un 


lector humano delatar rápidamente anomalías, sobre todo si 
un texto presenta estadísticamente más faltas de las esperadas 
incluso en un canal ruidoso, el enfoque se debe centrar, si esta 
propuesta es considerada en serio, en distribuir la información 
dificultando la tarea de programas automáticos en clasificar 
textos originales y textos con información oculta. Aunque no 
es sencillo articular una propuesta pública basada en estos 
principios, en [13] se presenta una aproximación interesante y 
razonablemente seria. La pregunta clave a resolver es ¿cómo 
sabe un programa automático que existe una falta de ortografía 
en un texto?. Con esta idea en mente se pueden formular 
diferentes sistemas de ocultación: 

a) Sistemas que usan malformaciones para producir palabras 
que no existen en un diccionario. El ataque a estas propuestas 
se simplifica utilizando diccionarios grandes y modelado de 
estadística de uso de las palabras. 

b) Sistemas basados en errores tipográficos y uso de 
acrónimos, abreviaturas y similares. La detección de estos 
procedimientos queda supedita a algoritmos similares a los 
utilizados en la corrección de textos (por ejemplo, en productos 
ofimáticos). Algunas de las técnicas que se emplean en su 
detección son medidas basadas en la mínima distancia de 
edición, modelos estadísticos n-gram, etc. 

c) Malformaciones que provocan que una palabra válida 
se convierta en otra palabra válida (vaca/baca, toro/loro, etc), 
separar palabras compuestas (saca puntas/sacapuntas), errores 
gramaticales, etc. La detección de estos procedimientos re- 
quiere de técnicas avanzadas de reconocimiento lingúístico, 
etiquetadores precisos, técnicas de desambigliación y com- 
prensión semántica. 

Aparte de la aportación conceptual de [13], razonan una 
capacidad de ocultación de 1bit/1 palabra útil, no queda 
lo suficientemente claro el interés práctico de este tipo de 
propuestas. No ha sido posible avanzar en el análisis de esta 
propuesta concreta al no poder acceder a la herramienta co- 
mentada en [13] y analizar la seguridad real de los estegotextos 
producidos respecto de un modelo de lenguaje obtenido de 
textos de entrenamiento, así como ver como se comportarían 
estos mensajes ocultos respecto de la estadística de un canal 
concreto donde se transmitieran. 

Analizadas muchas de las variantes esteganográficas más 
razonables en textos en lengua española se va a analizar a 
continuación algunas características de una red social concreta 
y se va a razonar si es productiva en términos de esteganografía 
lingúística. 


V. ESTEGANOGRAFÍA LINGUISTICA EN TWITTER 


La red social twitter es un buen ejemplo de red social donde 
el tamaño de los mensajes dificultaría ocultar centenas de bits 
(sin trocear o distribuir estegotextos) mediante una propuesta 
esteganográfica pública. En el pasado esta red ha sido utilizada 
de manera muy diversa, en el envío de información cifrada, la 
administración de botnets, etc [14][15]. 

Es en este entorno donde podría ser interesante analizar si 
también es útil en esteganografía lingiística, conclusiones que 
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se podrían derivar a otras redes similares. 

Si se piensa por un momento en este tipo de redes, es 
factible la implementación de un número elevado de pro- 
cedimientos esteganográficos basados en oscuridad y que en 
muchos casos recuerdan a procedimientos utilizados siglos 
atrás (utilizar ciertas letras, usar el número de palabras para 
codificar una información, etc). Por ejemplo, sería posible 
utilizar procedimientos clásicos de alterar las letras de cada 
palabra poniéndola en mayúscula o minúscula en función 
de si se codifica un bit O o un bit 1, de esta forma en el 
mejor de los casos se podría ocultar 140 bits (140 caracteres) 
por mensaje twitter. Como puede observarse sería fácilmente 
detectable, no obstante siempre podría ser utilizado como 
mecanismo para transmitir más información en los mensajes 
sin fines esteganográficos (en el mejor de los casos 140 bits/7 
bits-carácter = 20 caracteres más) teniendo el receptor la 
capacidad todavía de comprender el mensaje publicado. Sin 
ser puramente lingiiística otras técnicas de ocultación podrían 
ser factibles. Por ejemplo, usar los sistemas de codificación de 
urls compactadas utilizadas en Twitter, como por ejemplo el 
sistema web bit.ly, con fines esteganográficos. Por ejemplo, un 
enlace compactado del tipo bit.ly/aWvi3x podría ocultar infor- 
mación jugando con la codificación de los mismos (minúscula, 
mayúscula y números). Si se toma la molestia de que el enlace 
realmente exista (existen un gran número de ellos), un atacante 
no sólo debería comprobar que ese enlace apunta en realidad 
a una página web sino tener la capacidad a) de analizar la 
semántica de la frase donde está presente y correlarla con el 
contenido del enlace para ver si el enlace corresponde a lo 
que se indica o b) establecer algún tipo de criterio estadístico 
que permita deducir que de la presencia de muchos enlaces 
de este tipo se puede destacar la presencia de un sistema de 
codificación concreto. Como se describirá posteriormente la 
presencia de direcciones web en un mensaje Twitter se produce 
en un 23,23% de los casos. 

En cualquier caso, para analizar mejor el potencial de la 
esteganografía ligilística en esta red, se decide la construcción 
de un corpus basado en 103 usuarios españoles de la red 
twitter, con la condición que tengan al menos 1.000 seguidores 
y como poco 3.200 mensajes publicados (número máximo 
accesible por la web). La intención es medir en un grupo de 
comunicaciones normales, que pretenden ser entendidas por un 
conjunto amplio de usuarios, como se comunican los emisores 
y si esa comunicación permite extraer alguna conclusión con 
utilidad esteganográfica. Se intenta evitar, por tanto, jerga 
propia de un conjunto reducido de usuarios y sí la expresión 
de mensajes que desean ser leídos por una mayoría pero 
que pueden tener las características o comodidades propias 
del canal donde se emiten. Se busca por tanto un modelo 
estadístico común de conducta con utilidad esteganográfica. 
Se implementa un crawler en lenguaje JAVA y se recopila esta 
información construyendo un corpus final de 319.381 frases 
y 4.029.257 palabras [16]. Para el etiquetado de este corpus 
se implementa un programa en lenguaje JAVA que utiliza el 
etiquetador TreeTagger [17] considerando un mensaje Twitter 
como una frase [16]. La primera característica interesante 


detectada es que sólo se consume en media 48,1214% de 
la capacidad total (67 caracteres por frase), con la presencia 
por tanto de frases cortas e información muy instantánea lo 
cual da muestra de la presencia mayoritaria de adverbios 
de lugar y tiempo. El 38,57% de las frases empiezan con 
(2, un 6,32% con RT, acaban con emoticon un 6,21% y 
acaban con direcciones web un 23,23%. A la vista de este 
estudio, lingilísticamente más ampliado en [16], no parece 
factible en primera aproximación ocultación lingiística por 
procedimiento público, a excepción de las técnicas comentadas 
con anterioridad y ocultando menos información (al ser los 
mensajes twitter de pocas palabras). 

Aunque al seleccionar un conjunto de usuarios públicos 
no se esperaba un número notorio de faltas de ortografías 
(que podría tener utilidad en esteganografía). En la siguiente 
tabla se recopilan algunas mediciones sobre faltas de ortografía 
donde se observa, al menos para éstas y en el corpus recopi- 
lado, que este tipo de técnicas basada en estos fallos no sería 
muy productiva desde el punto de vista de la esteganografía 
lingúística. 


N? total 
102.179 
847 


Palabra+o+Palabra que 11 
empieza por 'o' | ocurrencias 


Estructura 
Punto+espacio+Término 


Palabra+y+Palabra que 42 
empieza por j ocurrencias 


Ocurrencias | N? palabras 
palabras 4.027.746 


Palabra acabada en "cion” 1544 0,0383% 
Palabra acabada en "sion" 0,0167 % 
14 


4 
Adverbio acabado en 


"mente” (que debería ir 
acentuado) 

Fig. 3. Medición de algunas erratas y faltas de ortografías de fácil 
computación. 


Omisión de tildes en: 


Podría ser interesante orientar la investigación en este tipo 
concreto de redes sociales (frases breves) al uso de gramáticas 
libres de contexto (CFGs) [18]. En el pasado no se consideró 
este tipo de estructuras desde un punto de vista práctico 
debido a la problemática de que para crear estegotextos con 
una cierta cohesión-coherencia se necesita la creación de 
gramáticas complejas (cuya automatización no es trivial) y 
diccionarios de gran volumen de palabras con categorizaciones 
semánticas. En el caso de twitter o similares este problema 
puede ser minimizado en gran medida. En twitter los mensajes 
son frases sueltas, sin necesidad alguna de que se mantenga 
una coherencia global con las frases publicadas anteriormente. 
De hecho en la práctica muchas de las frases no tienen 
nada que ver con sus antecesoras. Considerando esto sería 
factible profundizar en la investigación de reglas gramaticales 
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simples y la ocultación estar basada en la selección de palabras 
concretas (que se eligen de un conjunto W categorizado 
semánticamente y por PoS/probabilidad) para cada parte de 
la regla gramatical definida. En la práctica, es aunar los 
conocimientos en modelos N-GRAM, etiquetado lingúístico 
y sustitución de sinónimos según contexto para avanzar en 
un tipo evolucionado de CFG probabilística. Si esto fuera 
así, y a falta (en el momento de escribir este artículo) de 
una implementación real, la información a ocultar se cen- 
traría en las categorías lingiísticas más probables (nombres, 
verbos, adjetivos y adverbios en este orden). La capacidad 
de ocultación dependería del sistema de codificación elegido, 
si la codificación tiene el mismo peso para cada palabra a 
seleccionar hablaríamos de una capacidad de log W (base2) por 
término de la regla gramatical habilitada. Independientemente 
de otros criterios de aceptabilidad, un mensaje twitter podría 
ocultar como poco del orden de 3*logWi (base2) bits, siendo 
Wi el conjunto de palabras para cada elemento de la regla 
gramatical considerada, dado que una frase sencilla al menos 
podría tener un nombre, verbo y complemento. 

Las gramáticas CFGs son muy efectivas  es- 
teganográficamente para este objetivo, una especie de 
adaptación de la herramienta NICETEXT [18] con las 
indicaciones resaltadas anteriormente. A falta de una 
implementación real, queda pendiente analizar si un detector 
sería capaz de inferir anomalías que detectaran la presencia 
de información oculta por estos procedimientos. 


VI. CONCLUSIÓN 


En el último año y medio se ha avanzado en el análisis de la 
seguridad de propuestas públicas de esteganografía lingúística 
en lengua española. Las cifras actuales indica que la capacidad 
de ocultación es baja y requiere del uso de al menos textos de 
centenas de palabras para ocultar una cantidad de unos 128 
bits útiles para distribuir una clave criptográfica, una url, etc. 

El uso masivo de las redes sociales hace interesante analizar 
la posibilidad de ocultación de información en texto digital 
en ellas. En la práctica, redes sociales como tuenti, facebook, 
twitter o similares por la inmediatez provoca que en media los 
mensajes intercambiados sean de decenas de palabras. Esta 
limitación hace que sin trocear o distribuir los estegotextos 
creados, en frases o otras unidades lingúísticas, los proced- 
¡mientos esteganográficos analizados serían más apropiados 
en blogs y si acaso en comentarios algo extensos (centenas 
de palabras) en foros. 

La posibilidad de utilizar esteganografía lingilítica en re- 
des sociales con los procedimientos documentados, con una 
seguridad no basada en oscuridad, se complica bastante. En 
este orden se decide analizar cómo se expresa una comunidad 
de usuarios determinados en la red twitter y aunque aparecen 
elementos que permitirían crear algún modelo esteganográfico 
útil resulta difícil justificar su seguridad en una propuesta 
pública. 

Se deja abierto al futuro nuevos avances para mejorar las 
técnicas de esteganografía lingiística y su posible adaptación 
a nuevos canales masivos de comunicación, como las redes 


sociales o cualquier medio futuro que dificultara la detección 
de comunicaciones subrepticias a un potencial estegoanalista. 
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On the size of the colluder set 
in fingerprinting attacks 


Maria Bras-Amorós and Albert Vico-Oton 


Abstract—A classical attack to fingerprinting of digital contents 
is obtaining pirate copies by comparison of the licit copies of a 
set of colluders. A lot of research has been done for defining 
tracing algorithms for identifying at least one of the colluders 
that originated a given pirate copy. Our aim is to elaborate on 
the minimum number of colluders capable of generating a given 
pirate copy when the code used for fingerprinting is a Reed- 
Solomon code. 

Our main result is a lower bound on this minimum number. 
In the application side, having this lower bound means that once 
an illegal copy is caught, we can assert that at least a certain 
number of colluders, given by this bound, were involved in it. 
This result is illustrated with several examples showing that in 
many cases the bound is sharp. 

The bound is extended to partially-erased fingerprints. The 
result on partially-erased fingerprints can be used in turn for 
bounding the number of colluders that were not caught once a 
subset of the colluders is caught. 


Index Terms—Fingerprinting, polynomials over finite fields, 
Reed-Solomon codes 


IT. INTRODUCTION 


In the digital era one main concern is the illegal redistri- 
bution of digital contents. One way to fight it is by marking 
every single copy of the material that one does not want to 
have redistributed. This can be done by embedding a different 
imperceptible string of bits or symbols to each copy. Once 
an illegal copy is caught, if it was not modified, the illegal 
redistributor can be reidentified by the mark in his/her copy. 
This is called fingerprinting. 

An attack to fingerprinting can be performed by a group 
of colluders. They can compare their copies and create a new 
pirate copy by erasing all the bits or symbols in which their 
copies differ or by using at each position where they differ, 
the bit or symbol that one of the users has there. 

Formally, a subset of 2” for some alphabet % and positive 
integer n, called a code, is fixed. Then each depositary of a 
digital content is assigned a code word. A pirate copy is a 
vector u = (Up,...,Un—1) in 2”, which is obtained from a 
set of colluders as follows. If the code words corresponding to 
the colluders are cl), ..., c(*, then for all ¿in (0,...,n—1) 
one has u; = e for some ¡in (1,...,s), where e is the 
ith coordinate of ce). If erasures are also considered, then the 
pirate copy belongs to (2U(?4)”, and it must satisfy that for 
all 2, either u; = Ed for some ¿ or u¿ =?. If a pirate copy 
contains erasures we say that it is a shortened copy. 

Reed-Solomon codes are a classical family of error control 
codes which have been extensively used also in the context of 
fingerprinting. 

The identifiable parent property (IPP), for which all sets of 
colluders capable of generating a given pirate copy share at 


least one colluder, is defined in [1]. It is a desirable property 
when we are interested in the applications to fingerprinting. It 
1s proved in the same reference that there exist Reed-Solomon 
codes with this property. 

Another important property for fingerprinting codes is that 
given a pirate copy one of the colluders can always be 
identified by performing minimum distance error correction 
whenever the pirate copy has been created by at most a given 
number w of colluders. This property is denoted w-traceability 
or w-TA. Reed-Solomon codes are also used to find w-TA 
codes [2]. 

Further results on Reed-Solomon codes and the IPP and w- 
TA properties can be found in [3], [4]. Also generalized Reed- 
Solomon codes are used in [5] for dealing with shortened and 
corrupted fingerprints. 

While the classical problem of fingerprinting is defining 
tracing algorithms for identifying at least one of the colluders 
that originated a given pirate copy, our aim is to elaborate 
on the minimum number of colluders capable of generating a 
given pirate copy when the code used for fingerprinting is a 
Reed-Solomon code. 

Our main result (Theorem 2) is a lower bound on this 
minimum number. In the application side, having this lower 
bound means that once an illegal copy is caught, we can 
assert that at least a certain number of colluders, given by 
this bound, were involved in it. This result is illustrated with 
several examples showing that in many cases the bound is 
sharp. 

The tools used for proving the main result are then used to 
prove an upper bound on the minimum number 14 of colluders 
that can obtain any given pirate copy. This same bound can be 
also derived from the fact that Reed-Solomon codes are MDS. 
Using the main result we then see that this upper bound is 
sharp which means that there are certain pirate copies which 
can not be obtained with fewer than M colluders. 

The bound in Theorem 2 is extended to shortened finger- 
prints obtaining an analogous bound for this case. This result 
can be used in turn for bounding the number of colluders that 
were not caught once a subset of the colluders is caught. 

Finally we point out the main drawback of this bound 
and sketch the way to overcoming it by a closer look to 
the interpolated polynomial. We finish with an open question 
whose solution would bring out a significant improvement of 
our bound. 


TI. REED-SOLOMON CODES AND INTERPOLATING 
POLYNOMIALS 


Let IF, be the field with q elements (q a prime power) 
and let a be a primitive element of F,. Then F, = 
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[0,1,a,a?,...,0172Y. The Reed-Solomon code of length 
n =q— 1 and dimension k, denoted RS¿(k), is the set 


L(£(1), f(a), F(a?),..., f(0772)) : $ € Falz], deg(f) < k). 


First we notice that for each vector u = (Ug,...,Un—1) in 
IF, there exists a unique polynomial f, of degree at most 
n— 1 such that f,,(a*) = u; for all ¿in (0,...,n—1). It can 
be computed, for instance, using the formula 


The matrix of this system is a Vandermonde matrix which 
is known to be invertible. So, any u in F¿ is of the form 
(F(1), f(a), f(a?),..., f(a”7*)) for some unique f € F,[x] 
of degree less than n. 

Given a vector u = (Up, ...,Un-—1) in F¿, u is a code word 
if and only if deg(f.) < k. Now if deg(f.,) < k then u 
is a code word and so it can be obtained by just one single 
colluder. Our focus is on the case when u 2 RS¿(k) and so 
when deg(f.) > k. 


TI. A LOWER BOUND 


Lemma 1. With the same notations as above, a vector u = 
(uo, -..,Un-1) in Eq, u £ RS¿(k), agrees with any code word 
c E RS¿(k) in at most deg(f.,) positions. 


Proof: If the vector u agrees with a code word c in the 
position corresponding to the ¿th power of a this means that 
Filo) = fela?) and so (f, — fea?) = 0. Now since 
the number of roots of a polynomial over a finite field is 
upper bounded by its degree, the equality (f., — f.J(a*) =0 
will be satisfied by at most deg(f,, — f.) different powers 
of a. But since u 2 RS¿(k), deg(f.) > k and since 
c € RS¿(k), deg(f.) < k. So, deg(fu — fe) = deg(fu) 
and u = (up,...,Un-1) agrees with c in at most deg(f,,) 
positions. m 


Theorem 2. With the same notations as above, the mini- 
mum number of colluders required to obtain a vector u = 


(uo, -.-,Un—1) in Fz, with u 2 RS¿(k) is at least liza S 


Proof: It is a consequence of Lemma 1. u 
Next we will illustrate this theorem with basic examples for 
deg(f..) equal to 1,2 and n — 1, and then with two further 
examples dealing with the norm and trace polynomials. See [6] 
for more details on these polynomials related to finite fields. 
We will see that for the examples with deg(f,,) = 1 and most 
of the examples with deg(f,) = 2, and the examples with 
the norm and trace polynomials the lower bound is sharp. 
However, the example with deg(f,,) = n— 1 shows that the 
bound may be not sharp. 


a) The case deg(f.) == 1: Suppose first that 
deg(f..) = 1. This case only makes sense when k = 1 and so 
RS¿(k) is the repetition code. In this case a] equals 


n. Since deg(f.,) = 1 it holds that f, = ay + ax for some 
ao, a1 EF,, ar 40and so f,, represents a permutation of F,. 


The n different components of u can be covered by n =q=—1 
out of the q constant vectors of the repetition code. 

b) The case deg(f..) = 2: The case deg(f,) = 2 
makes sense when k = 1 or k = 2. In this case Era 
equals 2? if q is odd and £ if q is even. Since deg(f.,) = 2 
it holds that f,, = ap + a12+ ax? for some ay, a1,49 € Es, 
az % 0. Consider the set U = [apg+a18B+a28?, B € F¿). One 
can check that the equation on y given by ay +a18+a98? = 
ao + ar y + az)? has only two possible solutions, y = B and 
y == — B. The two solutions are equal only for those P”s 
such that P = 2 — P. Tf q is odd this is only possible for 
PB = a so U has exactly 27? + 1 elements. Conversely, 
if q is even then PB = — 2 — fB is true for all PB if a, =0 
and it is false for all B if a, 4 0. So, in the case q even the 
set U has either q elements if a, equals O and 3 if as 40. 
Now, the set of components of u is exactly the set of elements 
in Up = [ay + a18B + a28?, PB € F¿A (0). Now, for q odd, 
AU) = E if ar =0 and AU) = 2 +1 if as 40, while 
for q even, HU0 =q — 1 if as =0 and HU) = 2 if ar FO. 
So, if we take the repetition code, that is, k = 1 then the upper 
bound is tight only for q odd and as = 0 or for q even and 
ar 4 0. We will see in the next section that for k = 2 the 
bound is always tight. 

c) The case deg(f.) = n—1: If deg(f,) =n—1 then 
the upper bound on the number of colluders is [2%] = 2 
But the only information given by this bound is that one single 
colluder could not obtain u. And this is already known from 
the fact that u 2 RS¿(k). 

d) Example with the trace polynomial: Suppose q = q” 
for some prime power q and positive integer m. Then F¿ is 
a subfield of F,¿. The trace polynomial of the field extension 
F¿/F¿, is defined as the polynomial 


2 - 


Ta) = e 


The trace polynomial when evaluated at IF, gives ele- 
ments of F¿. The antiimage of each element in F¿ con- 


sists of exactly q"! elements in F¿. All this means 
(Ud, +++: Un=1) = 


that if we take the pirate word u = 
(T(1),T (0), T(a?),...,T(a”=1)) then u has for each £8 in 


EF¿| (0) exactly q"? components equal to 8 plus 71 — 1 
components equal to 0. In particular u can be obtained from 
the q colluders consisting of the constant vectors (B,...,/B) 
with P € F¿. These constant vectors are obtained by evaluating 
constant polynomials (with degree at most 0) in 1,a,..., an! 
and so they are code words of RS¿(k) for any k > 0. So, u 
can be obtained by only q colluders. 

On the other hand, since deg(T) =""7!* <q—1=mnm, by 
the uniqueness of f,, we have that f,, =T and so Paso! = 
[Es] = ==] = | 1] = (. So, we can see that in 
this case the bound in Theorem 2 is sharp. 


e) Example with the norm polynomial: We use now the 
same notations as before, just with the assumption that q X 2. 
The norm polynomial of the field extension F¿/Fg¿, is defined 
as the polynomial 
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The norm polynomial when evaluated at IF, gives also ele- 
ments of F¿. The antiimage of each element 8 in FF¿ consists 
of exactly qa elements in F, if P 4 O and exactly one 
if 6 = 0. All this means that if we take the pirate word 
u= (Uo,...,Un-1) = WO), N(a), N(a?), 06 MARE) 
then u has for each $ in F¿| [0] exactly “— components 
equal to 8. In particular u can be obtained from the q — 1 
colluders consisting of the constant vectors (8,...,/B) with 
PB E F¿| (0) which, as explained before, are code words of 
RS¿(k) for any k > 0. So, u can be obtained by only G— 1 
colluders. 

On the other hand, since deg(N) = e! <q=1=m, by 
the uniqueness of f,, we have that f,, = N and so Vaso | = 


[Hr] = [4-1] =G-— 1. So, we can see that again in this 


case the bound in Theorem 2 is sharp. 


IV. AN UPPER BOUND, REVISITED 


Theorem 3. A number of pa] colluders is enough for obtain- 
ing any pirate copy u € E. 


Proof: Consider a set of k positions 21,...,1z in u. The 
polynomial 
a y x— ol 
PS a AL a. 
l=1 j=1 
¡AU 
has degree less than k and so 


(FO), fla), f(a?),...,f(ar1) is a code word c in 
RS¿(k). Also c;, = f(a*) = u;, for all l in (1,...,k). Then 
c and u agree in the positions ¿1,...,1. The same argument 
holds for any selection of less then k positions. 


Divide u into [7] disjoint sets of k positions plus the set 


of the n — [2] remaining positions which are less than k and 
which may be empty. For each of these sets we can find a code 
word as before, which agrees with u in the selected positions. 
This gives a set of pa] code words capable of generating the 
pirate copy u. m 

We note that the proof of this theorem could have been much 
simplified by using the additional fact that Reed-Solomon 
codes are MDS. We chose this proof because it only uses 
the same tools used for the previous theorem. 

From Theorem 2 we deduce that the bound on the number 
of colluders in Theorem 3 is attained when f,, has degree 
exactly equal to k. So, there are words in F¿ which can not 


n 


be obtained by fewer than 2] colluders. 


V. ON SHORTENED FINGERPRINTS 


In this section we make some remarks on the case when part 
of the fingerprint has been simply erased. Tracing of traitors 
based on shortened fingerprints is treated in [5]. We show that 
the results in the previous sections can be naturally extended 
to this case. 

Formally, instead of considering pirate copies in F¿ we 
consider pirate copies u = (up,...,Un—1) in (EF, U (?p)” 
which are obtained from a set of colluders as follows. If the 
code words corresponding to the colluders are c),... ct), 


then for all ¿ in (0,...,n— 1) one has u, = 5 for some 
jin(1,...,sj, or u, =?. We call n* the number of erased 
positions in u, that is, the number of components u, which 
are equal to ?. Now n — n* will play the role played by n in 
the previous sections. 


The polynomial f,, can be redefined as follows. 


n-—1 Y ad 

A 
i=0 j=0 
¡Ai 


The vector (f.(1), fu(a),..., fula”71)) has the particularity 
that it agrees with u in all the non-erased positions and that 
it is the one with smallest degree with this property. Notice 
that now the degree of f,, is at most n— n* — 1 and that f, 
1s, as before, the unique polynomial agreeing with u in all 
the non-erased positions and with degree at most n— n* — 1. 
Uniqueness follows as before using a Vandermonde matrix. If 
n* = ( then the polynomial f., is the same polynomial that 
we already had. 

If des(f..) < k and in particular, if n—n*—1 < k then 
(fu(D), fula),-.., fula”72)) is a code word and so u agrees 
with a code word in all its non-erased positions. So, it can 
be obtained with just one colluder. Next we consider the case 
deg(fu) > k. 

Lemma 1 and Theorem 2 can be now reformulated. The 
proof of the new lemma is parallel to that of Lemma 1 and 
hence it has been omitted. Also, the proof of the new theorem 
follows from the lemma. 


Lemma 4. A vector u in (F¿U4(?p)”, u 2 RS¿(k), agrees 
with any code word c € RS¿(k) in at most deg(f.,) positions. 


Theorem 5. Suppose that a vector u is in (F¿U(?j)”, and 
u E RS¿(k). Then the minimum number of colluders required 


n—n 


deg(fu) 


We would like to end with the remark that this result can be 
used in turn for bounding the number of colluders that were 
not caught once a subset of the colluders is caught. Indeed, 
suppose that a set of colluders is caught that collaborated in 
the pirate copy u. Then erase all the positions of the pirate 
copy which agree with the copy of at least one of the caught 
colluders and obtain a new pirate copy u*. Let n** be the total 
number of erased positions in u*. Then, Theorem 5 applied 


* 


to obtain u is at least 


io] colluders are still not 


* 
to u* tells us that at least den 


caught. 


VI. DRAWBACK AND OVERCOMING IT BY A CLOSER LOOK 
TO POLYNOMIAL FACTORIZATION 


In Table I there is an analysis of the performance of the 
bound in Theorem 2. It turns out that Vaso | is most of 
the times 2 and this does not introduce any information. 
Indeed, having at least two colluders is equivalent to having 
u not a code word, which is something that is very easy 
to check without any need of interpolating polynomials. The 
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coalition mean value m 


. n 
ia size tnials of deg( fu) [el 
2 100 24.95 2 
3 100 24.99 2 
4 100 24.95 2 
5 100 24.95 2 
6 100 24.95 2 
7 100 25.00 2 
8 100 24.98 2 
9 100 24.94 2 
coalition A mean value m e 
BER size Hals of deg( fu) El 
2 100 24.96 2 
3 100 24.96 2 
4 100 24.98 2 
5 100 24.97 2 
6 100 24.96 2 
7 100 24.96 2 
coalition A mean value m de 
QS size Hals of deg( fu) [al 
2 100 24.97 2 
3 100 24.98 2 
4 100 24.97 2 
5 100 24.97 2 
6 100 24.96 2 
TABLE I 


WE CONSIDER R.927(3), RS27(4), AND RS27(5). FOR EACH OF THESE 
CODES AND FOR EACH COALITION SIZE s FROM s = 2 TO s = [F], WE 
GENERATED 100 PIRATE COPIES u, EACH ONE RANDOMLY OBTAINED 
FROM s RANDOM COLLUDERS. WE COMPUTED THE MEAN m OF deg( fu.) 
AMONG THESE 100 PIRATE COPIES. THEN WE COMPUTED [7], WHICH 
SHOULD GIVE AN IDEA OF WHAT WE CAN EXPECT FROM THE BOUND IN 
THEOREM 2. 


reason for having Vaso | = 2 most of the times is that 
having [7,31 > 2 would mean deg(f.) < 3 and, if 
fu = 4 +a12+...+ 0,2771, this would mean having 
día] = «+. = Gp-1 = 0, which happens only with a 
probability CAR =g 21 

The limitation of this bound already comes from Lemma 1 
and the fact that, in its proof, we only bound the number 
of roots of the polynomial f, — f. (and so the number of 
agreements between the caught word u and a general code 
word c) by the degree of f,,— f. which is exactly the degree of 
f... But conversely, it is well known that a random polynomial 
from F,¿[x] has “on the average”, as q increases, exactly one 
root in the field FF, [7], [8], [9]. So, on average, our bound 
in Lemma 1 is very far from the real number of agreements 
between the caught word and a general code word. 

But we have more information on the polynomial f. — fe 
rather than its degree. Indeed we know all its terms of degree 
at least k. In some cases this knowledge may slightly modify 
the result in Lemma 1 and this may improve drastically the 
bound in Theorem 2. 

In the next lemma we illustrate 1t with a particular example. 


Lemma 6. Suppose that q = q" for some prime power q and 
positive integer m. Suppose that u € F”, u 2 RS¿(k) with 1 < 
k <q"! is such that f., = an +27 +91 (0), 
with 71 < k < € and gy (x) a polynomial of degree less than 
k. Then the word u agrees with any code word c € RS¿(k) 
in at most (k — 1)4 positions. 


Proof: Suppose that u and c agree in the position corre- 


sponding to a* and suppose that T(a*) = B € F¿. Then a? is 
a root of the polynomial 


hglx) = fula) — folx) — Tlzx) + f. 


In general, all the powers a* corresponding to positions where 
u and c agree are roots of hg(x) for some 8 € F¿, and so 
they are roots of 


H(=)= || rato). 
PEF 
By the hypothesis on f.,, deg(f, — Tlx)) < k and also 
deg(f.) < k and deg(P) < 0 < k. So, deg(hg) < k for 
all $ € F¿ and deg(H) < (k — 1)g. This proves the Lemma. 
E 

Lemma 6 leads to a refinement of the bound in Theorem 2 
for this particular case, whenever (k — 1)g < deg( f.,). Indeed 
the new bound is anal: 

An analogous lemma associated to the norm polynomial 
is presented next. The proof is left to the reader since it is 
very similar to the previous one. The only difference is on the 
fact that the norm polynomial evaluated at powers of a: runs 
F¿1 (0) while the trace polynomial runs all F¿. 


Lemma 7. Suppose that q = q'” for some prime power q and 
positive integer m. Suppose that u € Fr, u 2 RS¿(k) with 


1<k< E? is such that f,, = cr + gu[x), with gí(x) 
a polynomial of degree less than k. Then the word u agrees 
with any code word c € RS¿(k) in at most (k — 1)(G— 1) 


positions. 


In this particular case the bound in Theorem 2 would be 
improved to la=na-n!: 

We leave it as an open question to have an equivalent 
of these lemmas for general polynomials. That is, given a 
polynomial f(x) we wish to have an upper bound on the 
number of roots of the polynomial 2*f(%) + gr(x), with 
deg(gx(x)) < k, depending only on k and f(x). This is 
obviously solved for the case of a constant polynomial f(x) 
and in this case the bound is exactly k. For the general case 
we would like the bound to be smaller than k + deg(f). 


VII. CONCLUSION 


We used some of the very special properties of Reed- 
Solomon codes to bound the minimum size of a collusion 
party, once a pirate copy built from a set of colluders is caught. 
Some experimental research brought to light a drawback 
of our bound. We elaborated on this drawback and gave 
some solutions for particular cases. This lead to an open 
question about polynomial factorization over finite fields for 
polynomials whose larger order coefficients are known. 
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Abstract—Los códigos de fingerprinting se utilizan para dis- 
uadir la redistribución de contenidos digitales por usuarios 
legales pero deshonestos (traidores). En este contexto, los códigos 
con la propiedad de trazabilidad (TA) tienen una importancia 
destacada, dado que permiten identificar eficientemente, por lo 
menos, a uno de los traidores que ha participado en la redis- 
tribución. Los códigos con la propiedad identificadora de padres 
(IPP) también tienen esta capacidad de identificación, pese a que 
no poseen, en general, un algoritmo eficiente de identificación. 
Otros códigos que tienen una capacidad de identificación más 
débil son los códigos seguros contra incriminaciones (SFP). Es 
un resultado conocido que un código TA es un código IPP y que 
un código IPP es un código SFP. Sin embargo, las implicaciones 
en sentido contrario no son ciertas en general. Pese a eso, se 
sospecha que en el caso de los códigos de Reed-Solomon estas 
tres propiedades son equivalentes. En este artículo se investiga 
esta equivalencia y se proporciona una respuesta afirmativa para 
familias de códigos de Reed-Solomon en los que el número 
máximo de traidores divide al tamaño del cuerpo del código. 


I. INTRODUCCIÓN 


Dentro del campo de la distribución de contenidos digi- 
tales, la técnica del fingerprinting aparece como una posible 
solución para disuadir a usuarios deshonestos (traidores) de 
redistribuir copias de un contenido que han obtenido de forma 
legal. Con este fin, el distribuidor del contenido incrusta una 
marca, llamada huella digital o fingerprint, en cada una de 
las copias que va a distribuir. Este proceso debe aunar dos 
propiedades: primero, la inserción de la marca en el contenido 
debe realizarse de forma robusta e imperceptible para los 
usuarios; y segundo, debe insertarse una marca única para 
cada uno de ellos. Esto hace que cada usuario posea una 
copia del contenido personalizada, única, hecho que le disuade 
de distribuir su propia copia, puesto que de hacerlo, será 
fácilmente identificado. 

No obstante, existe un punto débil en este esquema. Un 
grupo de traidores puede formar una coalición, comparar cada 
una de sus copias y determinar en qué partes son diferentes. 
Obviamente, las posiciones del contenido en las que difieren 
sus copias son posiciones en las que sus respectivas huellas 
digitales también difieren. De esta forma, los traidores pueden 
crear una nueva copia del contenido (copia pirata) alterando 
estas posiciones detectadas con el fin de que la copia pirata 
contenga una marca híbrida que no permita identificar a 
ninguno de los participantes de la coalición. Es más, podrían 
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llegar a crear una copia pirata que contuviese la huella digital 
de algún usuario inocente, o fuese muy similar a ésta. 

Llamamos al conjunto de marcas de usuario código de 
fingerprinting. Este código debe construirse de forma que, 
por lo menos, se garantice la protección de usuarios inocentes 
frente a una falsa incriminación. Un esquema más robusto 
debe permitir, además, identificar a usuarios traidores. Los 
códigos empleados en fingerprinting se clasifican en función 
de estas capacidades para proteger a usuarios inocentes o iden- 
tificar a traidores. Estas propiedades no son equivalentes en 
general. Habitualmente se requieren condiciones más restric- 
tivas para identificar a traidores que para proteger a usuarios 
inocentes. Sin embargo, existe la conjetura de que para el 
caso de los códigos de Reed-Solomomon estas propiedades 
(Mamadas en conjunto propiedades de trazabilidad) se cumplen 
simultáneamente y no se pueden disociar. En este artículo se 
investiga esta conjetura, planteada en [1], [2]. 

El artículo se organiza de la siguiente manera. En la sigu- 
¡ente sección, introducimos el tema y presentamos la notación 
que se utilizará. En la sección III presentamos el resultado 
principal del artículo, demostrando que las propiedades de 
trazabilidad son equivalentes para determinadas familias de 
códigos de Reed-Solomon. También presentamos un algo- 
ritmo para encontrar conjuntos de marcas en el código que 
demuestran esta equivalencia. En la sección IV ilustramos 
el funcionamiento del algoritmo mediante un ejemplo. En 
la sección V comentamos la equivalencia de las propiedades 
para otros tamaños de coalición y finalmente presentamos las 
conclusiones del artículo. 


TI. PRELIMINARES 


Dado el cuerpo finito de q elementos, IF,¿, denotamos los 
vectores de n coordenadas sobre IF, en negrilla, por ejemplo, 
a = (a1,...,dn) E F¿. En particular, 1 (lo... o, 1), 
Denotamos la distancia (de Hamming) entre dos vectores 
a, b € F7 por d(a, b). 

Un (n, M, d)-código C sobre IF, es un subconjunto de FF; de 
tamaño M tal que la distancia mínima entre sus elementos es 
d. Habitualmente nos referiremos a los elementos de C como 
palabras código. Si C es un F¿-espacio vectorial de dimensión 
k, diremos que C es un [n, k, d]-código. 

Consideraremos que el conjunto de marcas que el dis- 
tribuidor inserta en las copias antes de distribuirlas es un 


código C( € lia Cada t € C identifica unívocamente a un 
usuario. En adelante, designaremos por t indistintamente tanto 
la marca asociada a un usuario como al usuario en sí. 

Como se ha comentado antes, si una coalición de c usuarios 
deshonestos compara sus copias podrán detectar un cierto 
número de posiciones donde sus copias, y por lo tanto sus 
marcas, difieren. Asumiremos que una coalición sólo puede 
crear copias pirata en las que solo estén alteradas las posi- 
ciones detectadas. Esto se conoce habitualmente en la literatura 
como marking assumption [3]. 


Definición 1. Sea C un (n, M, d)-código sobre E, y T un 
subconjunto de C de tamaño c, T = 4t!,...,t*%). Diremos 
que x € EF es un descendiente de T' si para cada coordenada 
1<1<m existe un j, 1 < j <<, tal que x, = tl. Diremos 
también que tJ es un padre de x. El conjunto de todos los 
posibles descendientes de T se denota por desc(T”. 


También asumiremos, como en [1], [2], [4]-[6], que el 
conjunto de copias pirata que una coalición T7' puede generar 
es desc(T'). Denotaremos por desc.(C) el conjunto de todos 
los descendientes que pueden ser generados por cualquier 
subconjunto Y” € C de tamaño máximo c. Si suponemos 
que en nuestro esquema de distribución de contenidos no 
se producirán coaliciones de tamaño mayor que c entonces, 
el conjunto de marcas pirata que existirá será precisamente 
desc. (C). 


Definición 2. Un (n, M, d)-código C es (c,,cz)-seguro con- 
tra incriminaciones (SFP, de la denominación inglesa se- 
cure frameproof) si cualquier par de subconjuntos disjuntos 
T¡,Ta € C de tamaño máximo Cc, y Caz respectivamente 
satisfacen que sus conjuntos de descendientes son también 
disjuntos. 


Es decir, utilizando un código (c1,c2)-SFP (véase [2], [7)), 
ninguna coalición de tamaño cy podrá generar en el contenido 
pirata la marca que cualquier otro conjunto disjunto de hasta 
C2 usuarios hubiese podido generar, y viceversa. 


Definición 3. Un (n, M, d)-código C tiene la propiedad c- 
identificadora de padres (IPP, de la denominación inglesa 
identifiable parent property) si para cualquier x € Fo se 
cumple que x E desc¿(C”), o 


N 


T:xEdesc(T) 
[T|<c 


TH0. 


En otras palabras, utilizando un código c-IPP, la intersección 
de todas las coaliciones de tamaño máximo c capaces de 
generar x no es nula. En particular, las palabras código que 
pertenecen a la intersección corresponden a usuarios que han 
participado en la construcción del contenido pirata y por lo 
tanto, pueden ser identificados. 


Definición 4. Un (n, M, d)-código C tiene la propiedad de 
c-trazabilidad (TA) si para cualquier subconjunto T' € C de 
tamaño máximo c satisface que d(x,t) < d(x, y) para algún 
teT y cualquier y € CNT. 
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Dada una palabra pirata, ambas familias de códigos IPP y 
TA permiten identificar, por lo menos, a uno de los traidores. 
La principal diferencia es que el proceso de identificación se 
ejecuta en tiempo OU )) para códigos IPP mientras que para 
códigos TA se reduce a O(M). Es fácil ver que la propiedad 
TA es más fuerte que la propiedad IPP [5]. 


Definición 5. Dado un (n, M, d)-código C. sobre E, y dos 
subconjuntos de éste, V,W CC, V = ([v!,v?,...) W = 
[w!,w?,...), definimos la separación de grupo entre V y 
W, D(V,W), como el número de coordenadas donde los 
elementos de V y W contienen elementos disjuntos, es decir 


D(V,W) =|(i:fv1,v2,...)Nfwi,w2,...=0)!. 


Sea C un (n, M, d)-código y dados dos enteros c,, ca deno- 
tamos por D., ¿, el mínimo valor de D(T, T2) entre cualquier 
par de subconjuntos disjuntos 71,73 € C de tamaño máximo 
C1 y C2 respectivamente. Ciertamente, D¡ ¡ = d. Además, 
diremos que 7, y Ta forman una (c,,cz)-configuración no 
separada si se cumple que D(T7,,T2) =0. 


Lema 6. Para cualquier [n, k, d]-código C y cualquier par de 
valores enteros c1,ca se satisface que 


maxíf0,d — (c1ca — 1)(n—d)j < Do, e, 
< max[0,d — (ec, + c2 — 2)(k— 1)). 


Demostración: Es inmediata considerando que el lema es 
una generalización de [6, Lema 2.3]. a 
Obviamente, para un [n, k, d]-código si d < (c, +c2-2)(k= 
1) el código no es (c,,c2)-SFP y si d > (c1ca — 1)(n— d) el 
código es (c,,c2)-SFP. En realidad, si cy = cz = c se obtiene 
que esta última condición puede traducirse en d > (1-1/c2)n, 
y en este caso, es un resultado conocido, que el código no es 
sólo (c, c)-SFP sino que también es c-IPP y c-TA. En general, 
para cualquier (n, M, d)-código tenemos que [5] 


c-TA > c-IPP (1) 


Un (n, M, d)-código es MDS si cumple con igualdad la cota 
de Singleton, M < q”7“+*1. En particular, los códigos MDS 
lineales satisfacen que n—d = k—1. Para este tipo de códigos 
se puede ver [6] que la primera de las implicaciones en (1) se 
cumple en sentido inverso. Es decir, todo código MDS lineal 
es c-TA si y solo si d > (1— 1/c2)n. 

Los códigos de Reed-Solomon son un tipo de códigos MDS 
lineales que, además, son cíclicos. Denotaremos por t% la 
rotación cíclica de t € F¿; en ¿ coordenadas hacia la derecha. 


d> (1- 1/c%n (c, c)-SFP. 


Definición 7. Sea o: un elemento primitivo de F¿. El código de 
Reed-Solomon de longitud n = q—1 y dimensión k, RS(n, k), 
se define como el conjunto 


RS(n, k) = ((£(1), f(a), f(07), ...., H(0172)) : 


f(x) € Falrla-1), 


donde F¿[x];-1 denota el anillo de polinomios sobre F,¿ de 
grado máximo k — 1. 


Si f(x) € F,[x]x-1, diremos que f(x) genera la palabra 
código t= (f(1),..., f(a27?)) C RS(n, k). 

En [1], [2] se planteó la cuestión de si es cierto que todos 
los códigos Reed-Solomon que cumplen la propiedad c-IPP 
también cumplen la propiedad c-TA. Sin embargo, para un 
gran número de códigos de Reed-Solomon resulta que no sólo 
c-IPP implica c-TA, sino que se satisface 


d > (1- 1/c%n S c-TA > cIPP > (c,c)-SFP. (2) 


En otras palabras, ya sabemos que si d > (1 — 1/c%)n 
no existen (c,c)-configuraciones no separadas. La cuestión 
planteada consiste en encontrar por lo menos una (c,c)- 
configuración no separada cuando d < (1 — 1/c2)n. 

Por último, describimos aquí una última convención que 
tomaremos. Dado un polinomio f(w) € F¿[x] podemos 
asociarle la aplicación f : Fy —> F, definida como x > f(x). 
Por abuso del lenguaje, nos referiremos a esta aplicación 
simplemente como f. 


III. EQUIVALENCIA DE LAS PROPIEDADES DE 
TRAZABILIDAD DE LOS CÓDIGOS DE REED-SOLOMON 


En este apartado presentamos el resultado principal de este 
artículo, que se resume en el siguiente teorema. 


Teorema 8. Sea RS(n, k) un código de Reed-Solomon sobre 
E, y c un divisor de q. Entonces, si la distancia mínima de 
RS(n, k) satisface d <n—n/c? el código no es (c, c)-SFP. 


Antes de presentar la demostración del teorema, introduci- 
mos un algoritmo para encontrar (c,c)-configuraciones no 
separadas en códigos de Reed-Solomon sobre FF¿ cuando se 
satisfacen las condiciones del Teorema 8. La demostración del 
teorema anterior seguirá el esquema del algoritmo. 


A. Algoritmo 


+ Entrada: Un código de Reed-Solomon sobre F,, 
RS(n, k), con distancia mínima d < (1 — 1/c%)n y un 
entero c divisor de q. 

+ Salida: Un par de subconjuntos T,T3 C RS(n, k) tales 
que forman una (c, c)-configuración no separada. 

1) Si c? > q entonces: 

a) Tomar c' = minfc, ny. 

b) Tomar un polinomio arbitrario de primer grado 
f(x) € F,[x],-1 y la palabra código que genera, 
t=(t1,...,tn). 

c) Retornar 


A=l:L< ect y 
To =(t459:0<j< [n/e] - 1). 


2) Si c? < q entonces: 
a) Tomar un subgrupo aditivo G_< F, de q/c? 
elementos. 
b) Construir un polinomio no trivial de grado mínimo 
Fu) € Fg[x],-1 que tenga como raíces de mul- 
tiplicidad 1 los elementos de G (la aplicación f 
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asociada a f(x) será un homomorfismo con imagen 
de tamaño c?). 

Tomar un subgrupo S < im f de c elementos y 
sus c clases laterales, Pi + 5,...,P.+5S. 

Tomar un valor aleatorio r,1<r<c. 

Retornar 


Ti =1B11:P.€P.+58) y 
D=ltili<jzel, 


donde t/ es la palabra código generada por el 
polinomio f;(x) = fla) —Pj,1<j<c. 


B. Correctitud del algoritmo 


El algoritmo considera dos supuestos en función del valor 
de c. El primer supuesto, c? > q, queda demostrado en la 
siguiente proposición. 


Proposición 9. Sea RS(n, k) un código de Reed-Solomon 
sobre F, y c un entero tal que c? > q— 1. Entonces, si la 
distancia mínima de RS(n, k) satisface que d <n—n/c? el 
código no es (c, c)-SFP. 


Demostración: Dado que se se cumple que el código 
es MDS, n q — 1 y considerando las restricciones del 
enunciado, es inmediato comprobar que k > 2. Es decir, el 
código contiene, por lo menos, palabras constantes y palabras 
generadas a partir de polinomios de grado 1. Tomemos un 
polinomio arbitrario de grado 1, f(x). La palabra que genera, 
t, será tal que sus nm coordenadas serán todas diferentes. 
Consideremos el conjunto de sus primeras c/ = minfc,n) 
coordenadas, C” = [t,,...,t.. Tomemos ahora rotaciones 
de la palabra t hacia la derecha, en múltiplos de c! coorde- 
nadas: t,4(9,120 ¿6 ..., 1 (mc) Es inmediato ver que si 
se toma el conjunto de palabras 73 definido en el algoritmo, 
para cada coordenada, por lo menos una de las palabras de T 
toma un valor en C”. Además |T»| = [n/c'] < c. 

Dado que el código contiene todas las palabras constantes, 
construimos T,, de tamaño c! < ce, como el conjunto de 
palabras constantes para cada uno de los elementos de C”. 
Así, para cada coordenada existe por lo menos una palabra 
en 7 y una palabra en 72 que comparten el mismo valor. 
Entonces T,T2 es una (c, c)-configuración no separada. Mi 

Para demostrar el segundo supuesto, c? < q, necesitamos 
demostrar antes los siguientes lemas auxiliares. 


Lema 10. Sea R un subgrupo aditivo de tamaño r del cuerpo 
finito F¿, R < F,. Entonces, si m divide a r existe un 
subgrupo S < R con |S| = m elementos. 


Demostración: El subgrupo S existe como consecuencia 
de los teoremas de Sylow [8]. Al 


Lema 11. Dado el cuerpo finito E, y un entero m divisor de 
q, entonces existe un polinomio no trivial f € F¿[x] de grado 
m tal que la aplicación f : E, => F,¿ es un homomorfismo 
aditivo. 


Demostración: Por el Lema 10, podemos tomar R = F, 
y un subgrupo G < R de m elementos, G = (91,...,9m), 


C 3 E 5 : c 2 5 k c 2 
(0 q, e 07,07 aa , 3 e 22 ata a.,Q 0 j ¿A a. 1 ¿a a sae, 16 9 ,1 aa at) 
is e a pa e a y : 
(eee ¡007 ,0 0, a 022,0 0 y 1. 0%, 6, y 0%, q? 03 a E) ? yl y) 15 a yQ da ) (3) 
3 16 3 22 14 22 13 3 14 14 16 9 13 9 22 16 9 13 
(a yQ yQ yQ QU ¿A yQ , , yQ ? , , ¡QU yQ ? yQ y 1 yQ ¿0 ¿4 , 2 0 ,0 yQ ) 
(a ¡QU yQ o y 1 yQ 1 y y ¡Q yQ yQ ¡Qe a y yQ y 1 ¡Q yQ yQ 1 ¡ yQ yQ ) 
(a? ae , o? , ar E ar ) o? ? o? Or y) ar ? ar ? o? , Q , o? ES a? ) o? Ned ? o? , o? ar ? o? El o? , o? , a? ) a? E Q Or ) (4) 
jo C 9 Cc Cc je y q Cc Q jo 
(a? E rod 0 , o ) rod ) a ? rod E o ? a 0? ? rod , Q 7 a? 7 rod y) a? ? rod y) d ? a? o? E rod ¿0% , a? , a ? a ? Q E] 0d ) 
y construir un polinomio que tenga los elementos de G como también las c clases laterales de S, B1 +5,...,P.+5, y los 


raíces de multiplicidad 1, 
fa) =p] [(-= 9), peF¿M 10). 
¿=1 


Nótese que, así como el polinomio f(x) se anula cuando se 
evalúa en cualquier elemento del subgrupo G, el polinomio 
Falx) = f(x) — f(6) se anula cuando se evalúa en la clase 
lateral 6 +G. Esto sucede porque f(x) evalúa al mismo valor 
para cualquier elemento de P + G. Además, 


Ha) =p] [Ez — 91) =P] [6 + 3) 
= 1” [[6e — 9) =-pP] | (= - 9i) =-F(z) 


La penúltima igualdad se cumple para m impar. Este es el 
caso de cualquier cuerpo de característica diferente de 2. Para 
cuerpos de característica 2 tenemos que —1 = 1 y la igualdad 
también se cumple. Por último, 


m 


Hao+y) =0]]60+v=9) ="] [0-4 + 9) 


= p] [e = (y =91)) = f-y (2) = fu) + (y) 


demuestra que f : F¿ —> F, es un homomorfismo aditivo. 
Nótese que ker f =G y |im f| = [F,/Gl. a 

Con la ayuda de estos resultados, podemos presentar la 

demostración del resultado principal del artículo. 
Demostración del Teorema 8: Vamos a realizar la de- 

mostración construyendo, de nuevo, una pareja de subconjun- 

tos del código que forma una (c, c)-configuración no separada. 

Si e? > q, el código no es (c, c)-SFP por la Proposición 9. 
Entonces, asumiremos de aquí en adelante que (e? < q. Bajo 
esta circunstancia, si c divide a q, c? también divide a q y 
por lo tanto q/c? es un valor entero. Como k— 1 =.n2m— d, 
porque el código es MDS, tenemos que k — 1 > q/c? +1. 
Considerando solamente el caso más restrictivo, k = q/ +1, 
quedará demostrado el resto de casos. 

Por el Lema 11 podemos tomar un polinomio f(x) no trivial 
de grado q/c” tal que f : F, —> F¿ es un homomorfismo 
aditivo. Además, sabemos que | im f| = c?. Tomemos ahora 
un subgrupo S < im f de c elementos. Esto es posible porque 
el Lema 10 garantiza la existencia de dicho S. Consideremos 
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polinomios 


fj(u) = fu) — Bj 


Obsérvese que estos polinomios evalúan a algún elemento 
del subgrupo S cuando f;,(w)— Pj € S, es decir, cuando 
f;(x) toma el valor de un elemento de la clase PB; + £. 
Como las clases laterales de S son una partición de im f, 
los c polinomios f;(x) replican el subgrupo S en posiciones 
disjuntas de im f. Es rutinario comprobar que el mismo 
argumento justifica la replicación de cualquier clase lateral 
By +5, 1<r< c. De esta forma, el conjunto de las palabras 
generadas por dichos polinomios Ta = [t%,1 < j < c), 
replican c conjuntos de c valores diferentes en c conjuntos 
de coordenadas disjuntas. Por último, tomamos el conjunto 
T¡ de las c palabras con valores constantes en una clase 
lateral arbitraria de S. Para esa clase lateral en concreto y 
para cualquier coordenada existe alguna palabra en Ta que 
toma un valor en dicha clase lateral. Entonces tenemos que 
T,, Ta es una (c, c)-configuración no separada. nm 

Por lo tanto, la demostración del Teorema 8 demuestra la 
equivalencia de las propiedades (1) para los códigos de Reed- 
Solomon cuando el tamaño máximo de la coalición es un 
divisor del tamaño del cuerpo. 


1<j<c. 


IV. EJEMPLO 


Tomemos el cuerpo F27 = Fz[x]/(2%+2x+1) con elemento 
primitivo a: = z. Consideremos que el tamaño máximo de las 
coaliciones es c = 3 y tomemos el código de Reed-Solomon 
RS(n = 26,k = 4). Tomemos ahora un subgrupo de F, de 
tamaño q/c? = 3, (0,1,a1%], y construyamos el polinomio 


Ha) =(0-0)(e— Deal?) = pla? +09). 


Por el Lema 11, la aplicación asociada al polinomio f(x) es 
un homomorfismo. La palabra generada a partir de él es 


(0, pee, da al, ar, ad, Q, ar, ar?, a? Q, Q, 
0%,0,1,02,1,0%, 03,0 01%, 021,0 0% 02), 
de donde es inmediato ver que im f =(0, 1, a, a%, Y, a, 


at%, al, a22]. Dado que c? = | im f|, tomamos, por ejemplo, 


el subgrupo S = (0,1,a1%) < im f de c elementos y sus c 
clases laterales: 

Br +5= 10, 1, ay 

Ba +5= la, a?,a?y 


B3 +9= [a*54 alfa), 


TABLA I 


ALGUNAS FAMILIAS DE CÓDIGOS RS(n = q 


1,k= [n/c? +1]): 


(a) códigos que satisfacen e > q; (b) códigos que satisfacen lg, (c) códigos que satisfacen (k — 1)|(q — 1) 


F, | 64 8l 125 128 243 256 512 625 729 1024 2187 F, [512 625 729 1024 2187 
c=2 [| (bd) (ce) (ce) (bd) —-  (b) (b) (ce) (e) (b) = ec=19| - (e) - (c) = 
31(0) (bb). - = (bh = = =  (b) = (b) 20-221 - (ce)  (c) (c) = 
41(0) () - (bd) —-  (b) (b) (co)  - (b) = 23-24 | (a) (ce)  (c) = = 

5 |(c) (ce)  (b) (b). - = = 251 (Y (b)  (c) = = 

8 | (b) (ce) (0) (by - (bd) (bp. - = (b) = 26 (a) (a) (o) = = 
213 (M6 () - (b) - (ce) (ce) (b) = (b) 271 (Y (a)  (b) S (b) 
101() (3) (co)  - = (H. =- = (e) (c) = 28311 (Y (a (a) = > 
Dl (a (Y) - (bb) (e) - (ce) (co) = = 2 (Y (a) (a) (b) Si 
1415 1(3 (Y (Y (ay (e)  - = (ce) (co) < = 3: (9 (a) (a) (a) = 
1610 QQ) GQ) Ga (a (0 ()- (b) = 3446 (Y (Y () (a) (c) 
Misa € € € (AY (1) - (co) - = = 24011(3 (a) (a) (a) (a) 


donde consideramos que 3, = 0, f2 =0 y B3 = a**. Ahora 
construimos los polinomios f,(x) = f(x)—P;,1 < j < c. Las 
palabras generadas a partir de ellos se muestran en (3), donde 
cada clase lateral P,+.S se ha coloreado de la misma manera. 
Se puede observar que las palabras código replican las clases 
laterales en posiciones disjuntas. Por lo tanto, pueden generar 
un descendiente común con cualquier conjunto de palabras 
que esté formado por palabras constantes en una de las clases 
laterales de S. Por ejemplo, podemos tomar la clase Pa + $, 
ilustrada en (4). Como vemos, los conjuntos de palabras (3) 
y (4) pueden generar un descendiente común (subrayado en 
(4)), y por lo tanto es una (3,3)-configuración no separada. 
De forma similar podríamos construir conjuntos para las clases 
Picks y Bs, 


V. RESULTADOS PARA OTROS TAMAÑOS DE COALICIÓN 


En [4] se presentó un resultado relacionado, demostrando la 
equivalencia de las propiedades de trazabilidad de para otras 
familias de códigos de Reed-Solomon. La idea consiste en 
reformular la condición de (c,c)-SFP algebraicamente como 
un sistema de ecuaciones. 


Teorema 12 ([4]). Sea RS(n, k) un código de Reed-Solomon 
sobre FF, tal que k=1 divide q 1. Entonces, si d < n—n/c 
el código no es (c, c)-SFP. 

Esto cubre familias de códigos de Reed-Solomon con c? > 
(q —1)/(k — 1) siendo (q — 1)/(k — 1) un entero. 


Proposición 13. Dado el código de Reed-Solomon RS(n, k) 
sobre F, con distancia mínima d y un entero c, si clq ó (k— 
D)l(q — 1) entonces, RS(n, k) satisface 


d > (1-— 1/c%)n e c-TA > cIPP > (c, c)-SFP. 


Iustrativamente, en la Tabla I mostramos algunas famil- 
las de códigos de Reed-Solomon, para determinados valores 
de c y q, tales que satisfacen (c,c)-SFP <= c-TA con 
k= [(q — 1)/c? + 1]. Esto sugiere una respuesta afirmativa 
a la pregunta planteada en [1], [2]. 
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VI. CONCLUSIÓN 


En este artículo hemos estudiado las propiedades de traz- 
abilidad de los códigos de Reed-Solomon. Nuestro principal 
objetivo era el de dar una respuesta a la pregunta planteada por 
Silverberg et al. en [1], [2]: ¿Es cierto que todos los códigos 
Reed-Solomon IPP son también TA?. Hemos demostrado la 
equivalencia de las propiedades SFP, IPP y TA para algunas 
familias de códigos de Reed-Solomon, cuando el tamaño 
de la coalición de traidores tiene la particularidad que su 
tamaño máximo divide el tamaño del cuerpo. Obviamente, 
esto no responde al cien por cien la pregunta planteada, pero 
esperamos que contribuya a aportar ideas que puedan ser útiles 
para encontrar la respuesta completa. 
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Resumen—El presente artículo presenta un estudio sobre la 
utilización de los códigos LDPC en aplicaciones de fingerprinting. 
Concretamente su utilización en entornos que sean susceptibles 
de ataques de confabulación. Aunque esta aplicación de los LDPC 
es nueva, los resultados aquí presentados demuestran que puede 
ser una buena solución para abordar este problema en entornos 
dónde se necesitan pocos usuarios, del orden de decenas de miles, 
y en los que el contenedor del fingerprint tiene una capacidad más 
bien pequeña. En este sentido se han conseguido probabilidades 
de éxito superiores al 98 % con 28 confabuladores de entre 1024 
usuarios. 


I.. INTRODUCCIÓN 


La protección de los derechos de autor o copyright se ha 
convertido en un tema importante dentro de la comunidad 
científica durante los últimos años. Aunque en primer término 
se abogo por sistemas que impidieran la replicación de los 
soportes, pronto se llego a la conclusión que estos sistemas, 
una vez rotos, nada podía parar la replicación ilícita. Durante 
la última década ha ido asentándose la idea de que quizás 
sería más apropiado enfocar el problema desde una óptica 
más proactiva: el fingerprinting. El concepto de fingerprinting 
fue introducido por Wagner en [1] como un método para 
proteger la propiedad intelectual de contenidos multimedia. 
La idea básica es generar copias del mismo contenido pero 
que, de alguna manera, puedan identificar su comprador. La 
finalidad del fingerprinting no es evitar las copias ilícitas sino 
disuadir a los usuarios de hacerlas. 


El principal ataque a los esquemas de fingerprinting son los 
ataques de confabulación, es decir, cuando dos o más usuarios 
se unen para comparar sus copias, encontrar diferencias y 
generar una nueva copia con partes de las tres que pueda 
ocultar sus identidades para evitar ser inculpados. El problema 
se agrava cuando no sólo no se identifica ninguno de los 
traidores sino que, además, se inculpa un usuario inocente. Por 
lo tanto, el objetivo del fingerprinting es encontrar un sistema 
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de marcas que ayuden a prevenir los ataques de confabulación. 


Boneh y Shaw presentaron en [2] una de las primeras 
propuestas sobre códigos seguros frente a confabulaciones. 
Su propuesta es capaz de identificar a un usuario ilícito entre 
una coalición de c usuarios con una probabilidad de error 
e. Su construcción se basa en el uso de un código interno 
binario y un código aleatorio como código externo. 


El rendimiento de los códigos LDPC conjuntamente 
con uno de sus algoritmos de decodificación soft como 
el algoritmo Sum-Product (SPA) como códigos seguros 
frente a confabulaciones será analizado en profundidad 
teniendo en cuenta su comportamiento en función de la 
longitud del código y el número de usuarios que forman 
la coalición. La capacidad del decodificador LDPC para 
identificar al menos uno de los traidores y el número de 
falsos positivos generados será de ayuda para discutir la 
eficacia de estos códigos en según que escenarios. En otros 
esquemas fingerprinting [3] se propone el uso de códigos 
LDPC para mejorar el rendimiento de los BIBD frente a 
ruido gaussiano, la idea en nuestra propuesta es utilizarlos 
directamente como código fingerprinting y no solamente para 
combatir el efecto del ruido en el canal. 


Este artículo esta organizado de la forma siguiente. La 
sección II presenta algunos conceptos y definiciones referentes 
al fingerprinting y a los códigos correctores de error. La 
sección III introduce los códigos Low-Density Parity-Check 
y el algoritmo de decodificación Sum-Product (SPA). Las 
contribuciones de esta propuesta son expuestas en la sección 
IV mientras que los resultados que de ellas se han derivado se 
presentan en la sección V. Finalmente, la sección VÍ resume 
las conclusiones de este artículo. 
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TI. ESQUEMAS DE FINGERPRINTING 


El fingerprinting es una técnica que consiste en incrustar 
alguna característica única en las copias de un contenido 
digital de forma que permita identificar una de estas copias 
de forma unívoca. 


La protección del copyright frente a redistribuciones de 
contenido digital es uno de los objetivos principales del 
fingerprinting. Cuando una organización trata de distribuir 
contenido digital protegido, un  fingerprint distinto es 
incrustado en cada una de las copias enviadas. El objetivo 
es que estos fingerprints se puedan usar como evidencia 
irrefutable para identificar el receptor o comprador de una 
copia concreta de este contenido. Si se detectan intenciones 
maliciosas, la extracción del fingerprint de la copia en conflicto 
debe ser prueba suficiente para inculpar al usuario fraudulento. 


Como los bits que forman el fingerprinting son distribuidos 
dentro del documento siguiendo algún patrón, para facilitar su 
posterior extracción, es de esperar la colaboración entre varios 
usuarios para conseguir realizar un ataque de confabulación. 
Nada les impide comparar sus copias y generar una nueva 
copia pirata que intente ocultar su identidad con el fin de 
no poder ser inculpados. Por lo tanto, uno de los requisitos 
más importantes exigidos a los códigos fingerprinting es que 
sean resistentes a confabulaciones de un cierto número de 
usuarios. 


En [2], [4], [5], [6] se discuten en profundidad las 
características necesarias para obtener un esquema de 
fingerprinting fiable. Estas características se pueden resumir 
en cuatro: mínima probabilidad de error o falso positivo, 
cardinalidad del código sustancial, longitud de código mínima 
y facilidad de rastreo. Como parece lógico, un código capaz 
de cumplir todas estás características puede ser imposible de 
encontrar ya que, en cierto modo, entran en contradicción. Por 
lo tanto, es primordial conocer los requisitos de la aplicación 
en concreto para cuantificar la importancia o relevancia de 
cada una de ellas. 


A continuación se presentan algunas definiciones útiles 
para centrar los objetivos de este artículo. Básicamente las 
dividimos en dos grupos, las relativas a la Marking Assumption 
y las relativas a los códigos n-seguros. 


II-A. Marking Assumption 


La Marking Assumption se puede considerar el principio 
básico en el diseño de los códigos fingerprinting. De 
hecho establece las reglas básicas relativas a los ataques 
de confabulación. Antes de definirla son necesarias unas 
definiciones previas. 


Dada 1, una palabra código de longitud n, tal que w € » 
y un conjunto Y] = (¿1,%3,*** ,¿y) donde 1 < r < n, 
entonces w |7 es la palabra (w;, ,0;,,**- ,;,) donde w, es 
el ¿ — ésimo elemento de w. w |, denota la restricción de w 


en las posiciones especificadas por /. 


Definition 1: (Código en [21) Un conjunto 
T = (uV0d we)... ,wtYj C Y!, donde Y denota un 
alfabeto de tamaño s, será referido como un (1,n)-código. 
La palabra código w(“:) será asignada a un usuario u;, para 
1 < 1 < n. Nos referiremos al conjunto de palabras de I' 
como código. 

Definition 2: (Posiciones indetectable en [2]) 
Sea To = (uWDjwY,-.-,weY) un (Ln)-código y 
Co = ([uj,ua,-:-,u.) una coalición de c-traidores. La 
posición ¿ será indetectable para C si las palabras asignadas 
a los usuarios en C' coinciden en la posición ¿-ésima, es decir 
q) == o, 

El concepto más importante recae en la definición de 
feasible set. Aunque se han publicado varias definiciones 
posibles para este concepto, la definición de Bonew-Shaw es 
la siguiente. 


Definition 3: (Feasible Set en (21) Sea 
T = (ww), --- w'WYy un  (Ln)-código y 
Co = [u¡,uz,-:-,u.) una coalición de c-traidores. Se 
define feasible set I' de C' como 

D(O) = [x= (21,:*: 2) E Y [1,€wj,,1<j<l) 


donde 


(ur) (u1) -=...— nue) 
wWj= (us) ea ) d A 
qu,“ [1Er<c Ur otherwise 
donde ? denota una posición borrada. 
Definition 4: (Marking  Assumption) Sea  I' 


(ww), --- ,w') un (L,a)-código, C = (uz, uz,--- ,Uc) 
una coalición de c-traidores y T(C) el feasible set de C. La 
coalición C' es solo capaz de crear un objeto cuyo fingerprint 
se encuentre dentro de T(C). 

Según esta definición, cualquier coalición sólo es capaz de 
detectar las posiciones donde los fingerprints difieren entre un 
usuario y otro. Por lo tanto, los usuarios maliciosos pueden 
escoger entre dejar uno de sus valores o bien introducir un 
borrado en una determinada posición. 


TT. 


Los códigos Low-Density Parity-Check o LDPC, fueron 
propuestos en primer lugar por Robert G. Gallager [7], [8] 
en 1962. Desafortunadamente, el trabajo de Gallager fue 
ignorado durante muchos años debido a la falta de recursos 
computacionales de la época. No fue hasta finales de los años 
90 cuando Mackay y Neal [9] empezaron a investigar códigos 
basados en grafos y decodificación iterativa. Hoy en día los 
LDPC gozan del reconocimiento que se merecen gracias a su 
elevado rendimiento que los sitúa muy cerca del límite de 
Shannon. De hecho, actualmente se consideran unos duros 
competidores con los Turbo códigos en cuanto a corrección 
de errores se refiere en entornos donde se necesita una elevada 
fiabilidad. Además los LDPC presentan importantes ventajas 
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respecto de los Turbo códigos ya que no requieren de un 
sofisticado entrelazador para ofrecer un rendimiento óptimo, 
su rendimiento en cuanto a error de bloque es superior, el 
suelo de error está situado en niveles de BER muy inferiores 
y su decodificación no se basa en trellis por lo que ofrecen 
una velocidad de decodificación mayor. 


HIFA. Códigos Parity-Check 


Un código parity-check de longitud N es un código bloque 
binario y lineal donde todas sus palabras código cumplen M 
restricciones lineales en cuanto a validación de paridades. 
El código se define mediante una matriz de paridad H de 
dimensiones M x N, cada fila de la cual especifica una 
determinada de las M restricciones. Por lo tanto el código 
parity-check es el conjunto de vectores c que satisfacen todas 
las M restricciones, es decir, c- 4% = 0. La característica 
diferencial de un LDPC es que en este caso, la matriz de 
paridad siempre esta definida de forma que sea poco densa, 
es decir, que contenga pocos 1. 


Definition 5: La matriz de un código (j,k) LDPC regular 
es una matriz binaria de dimensiones M x N que tiene 
exactamente j unos en cada columna y exactamente k unos 
en cada fila, donde ¿ <k << N. 

A partir de la definición anterior se puede deducir que cada 
ecuación de validación de paridad afecta a k bits, y cada uno 
de ellos afecta a exactamente j ecuaciones de validación de 
paridad. Para asegurar que el ratio del código no es nulo, la 
restricción j < k es necesaria para evitar precisamente que el 
vector nulo pueda satisfacer todas las restricciones. 


IIFB. Algoritmos de decodificación 


Los códigos LDPC pueden descodificarse utilizando tanto 
algoritmos de hard-decision o de soft-decision. Como regla 
general, los algoritmos de hard-decision, como por ejemplo el 
Majority-logic (MLG) o el Bit-flipping (BF), requieren menos 
complejidad de decodificación y suelen ser más rápidos. Sin 
embargo, su rendimiento es inferior en comparación con los 
algoritmos de soft-decision. Por otro lado, existen algoritmos 
basados en soft-decision como el de probabilidad a posteriori 
(APP) y el de decodificación iterativa basado en propagación 
de confianza (IDBP), también conocido como Sum-product 
(SPA), que, aunque penalizan la velocidad de decodificación, 
ofrecen un rendimiento sustancialmente superior. En este 
estudio se ha optado por el SPA ya que es el que ofrece 
un rendimiento mayor en cuanto a corrección de errores. A 
continuación vamos a definir algunos aspectos referentes al 
entorno de aplicación. 


Sobre un canal con ruido gausiano aditivo y blanco 
(AWGN) de media nula y PSD de Ny, se usa un código 
LDPC para control de errores. Una palabra código v = 
(vo, U1,...,Un—1) es codificada como la secuencia bipolar 
x= (£p,%1,...,%,-1) donde: 


+1 siv=1 


LT] = : 
=1 sivy=0 


Sea y = (Yo, Y1) + --,Yn—1) Una secuencia real recibida con 
y ==1+m;, siendo n, una variable Gaussiana aleatoria de 
media cero y varianza Zo. En este caso, la secuencia discreta 


z= (20,21,+..,2%n-1) se obtiene a partir de y mediante: 
l siy>0 
2 = Ñ 
0 siy<0 
Sea h1,ha,...,h.y la forma de denotar las filas de la matriz 


de paridad H, donde h; = (h;0,h;1,..- 
1< J, entonces, 


¿Min1) para 1 5 


s= (8858) =24 HB" (1) 


genera el síndrome de la secuencia recibida z, donde el ¿- 
ésimo componente s;, es dado a partir de la siguiente ecuación 


n—-1 
sa =2h =D ahi Q) 

1=0 
El vector recibido z será una palabra código si y solo 
si ss = 0. En caso contrario, significa que la secuencia 2 
contiene los errores indicados por las ecuaciones de paridad 
no satisfechas. El número de fallos en la comprobación de la 
paridad es igual al número de componentes distintos de cero 

presentes en s. 


El algoritmo SPA procesa los símbolos recibidos de forma 
lterativa para mejorar la fiabilidad de cada uno de ellos 
basándose en la computación de las validaciones de paridad 
a partir de los símbolos discretos y la matriz H. La fiabilidad 
del símbolo es medida mediante su ratio log-likelihood 
(LER). Esta fiabilidad medida al final de cada iteración es 
usada como entrada para la siguiente iteración. El proceso de 
decodificación continua hasta que se cumple un determinado 
criterio. 


La implementación del algoritmo SPA recae en la compu- 
tación de las probabilidades a posteriores marginales, P(v/|y), 
para 0 < 1 < n donde y es la secuencia real recibida. El LLR 
para cada bit se define como 


P(u = 1ly) 
P(u =0ly)' 


Existen varias versiones del algoritmo SPA. En las 
simulaciones presentadas en este artículo se usa el esquema 
presentado por Radford M. Neal y Bagawan [10], [11]. La 
mejora aportada en cuanto a la información extrínseca en 
cada iteración es usada para mejorar tanto la información 
extrínseca de salida como la fiabilidad de cada símbolo en la 
próxima iteración. El proceso continua hasta que se consigue 
encontrar una secuencia que satisfaga todas las restricciones 
impuestas por el código, es decir, la matriz H. 


L(v) = log (3) 
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IV. PROPUESTA 


El principal objetivo de esta propuesta radica en el análisis 
del rendimiento de los LDPC en escenarios donde aparecen 
ataques de confabulación. Estos entornos requieren esquemas 
con una importante fiabilidad y una elevada capacidad de 
encontrar como mínimo uno de los usuarios que han formado 
parte de la coalición, con el requisito ineludible de prevenir 
la inculpación de usuarios inocentes. 


El esquema propuesto consiste en la concatenación de 
códigos LDPC con un código de repetición para crear un 
fingerprint capaz de identificar cada usuario. En un primer 
paso, se generan () cadenas binarias aleatorias de longitud 
M bits, cada una de ellas será el identificador u; del 
usuario ¿ donde 1 < ¿ < Q. Todos estos identificadores 
u, son codificados mediante un código LDPC con un ratio 
de N/M = 2, generando (Q palabras código de longitud 
N = 2M. Cada bit de estas palabras código se codifican 
mediante un código de repetición, la longitud del cual se 
fijará en función de probabilidad de detección de colusión 
deseada en una determinada posición. En lo referente a la 
generación del código LDPC, se utiliza un código regular con 
una matriz de 3 unos por columna evitando ciclos de Tanner 
de grado 4. 


En nuestras simulaciones consideramos que cualquier sub- 
grupo de c usuarios entre los (2 usuarios pueden realizar un 
ataque de confabulación. Una vez la confabulación ha tenido 
lugar, suponemos que una cierta cantidad de ruido de canal 
puede ser añadido al objeto resultante de la confabulación. 
Finalmente, el resultado se descodifica mediante el algoritmo 
SPA y se aplica un mached filter basado en correlación. 

Un tema importante a tener en cuenta es el modelado 
de la confabulación. En este sentido, en las simulaciones 
se han considerado varias alternativas. Básicamente, cuando 
los confabuladores comparan sus copias advierten que en 
determinadas posiciones hay diferencias. Teniendo en cuenta 
la Marking Assumption, ante este hecho los confabuladores 
pueden actuar de distintas maneras. Cada manera o forma de 
actuar marcará un tipo distinto de confabulación: 


= Erasure o Borrado: En este caso deciden poner un valor 
no válido en esta posición. 

= Majority o Mayoría: En este caso deciden poner el valor 
más repetido entre sus copias. 

= Average O Media: El valor en esta posición refiere al 
valor de la media de los valores de todos los usuarios en 
esta posición. 

= Coin-flipping o Tiro de moneda: Deciden poner uno 
de los valores detectados de forma equiprobable entre 
todos los valores detectados. En el caso binario sería con 
probabilidad 1/2 cada valor. 


El decodificador LDPC implementado permite dos tipos 
distintos de salida: una palabra soft, es decir, la verosimilitud 
de los bits descodificados, y su correspondiente palabra hard. 
A partir de la salida del descodificador LDPC, se correlan los 


distintos identificadores de usuario con la salida soft o hard 
en función del esquema elegido. Finalmente se considera 
que el usuario con una correlación mayor es miembro de la 
confabulación y, por lo tanto, es inculpado. 


Con el objetivo de extraer conclusiones respeto al 
rendimiento de los LDPC como medida de protección 
frente a los ataques de confabulación, los resultados de las 
simulaciones se muestran en función de la probabilidad de 
identificación de traidores (TIP), es decir, cuantas veces el 
usuario inculpado ha participado realmente en el ataque de 
confabulación. 


En este artículo, el rendimiento de los LDPC en entornos 
con ataques de confabulación se ha evaluado en función 
del numero de confabuladores que pueden formar parte 
de la coalición, exigiendo un rendimiento mínimo de un 
TIP del 98%. Cabe destacar que se han usado códigos 
con una longitud extremadamente corta (128 y 256 bits) 
para las longitudes habituales en códigos fingerprinting ya 
que uno de los requisitos exigidos a nuestro sistema es 
un buen rendimiento con longitudes cortas ya que existen 
varios códigos fingerprinting con un buen rendimiento con 
longitudes grandes. 


V. RESULTADOS DE LAS SIMULACIONES 


El uso de códigos LDPC conjuntamente con el algoritmo 
de decodificación SPA usando propagación de confianza 
(IDBP) con 50 iteraciones es una potente herramienta gracias 
al vector de verosimilitud proporcionado por el decodificador. 
La clave reside en analizar los bits a la entrada intentando 
discernir cuales han sido detectados por los confabuladores y 
cuales no. Ayudar en esta tarea es el objetivo del código de 
repetición, básicamente, cuanto más largo sea el código de 
repetición, más fiable será el valor que utilizará el LDPC para 
descodificar. Una vez hecha esta estimación se asigna una 
mayor probabilidad a la entrada del descodificador a los bits 
que se considera que no han sido detectados. Como el SPA 
es el algoritmo escogido para todas nuestras simulaciones, 
esta asignación se comporta de la misma forma tanto en los 
casos de salidas hard como en salidas soft. 


Considerar que el usuario que tiene una mayor correlación 
con la salida del descodificador es inculpado, implica la 
posibilidad de inculpar un inocente si la correlación entre 
su identificador y la palabra descodificada es la mayor. Esto 
sucede cuando se produce un error en la decodificación y 
recibe el nombre de falso positivo. Los falsos positivos deben 
de evitarse o, como mínimo minimizarlos todo lo posible. 


V-A. Rendimiento del descodificador LDPC vs. número de 
confabuladores 


El número de usuarios que forman parte de la coalición 
guarda una relación directa con el rendimiento del sistema 
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y es un valor que el descodificador no conoce, es decir, 
a partir del fingerprint recuperado no hay forma de saber 
traidores han participado en la confabulación. 
Por lo tanto, es importante saber cuantos traidores puede 
soportar el decodificador al mismo tiempo sin que esto 
afecte gravemente su rendimiento, es decir, si que el TIP sea 
inferior al 98 %. En las simulaciones se ha considerado que el 


cuantos 


número de usuarios del sistema era 1024 (es decir Q = 1024). 


Las simulaciones realizadas utilizan un identificador 
de 128 o 256 bits (es decir, M = 128 o M 256) y, 
como el codificador LDPC escogido presenta una relación 
de M/N 1/2, la salida, N, será de 256 o 512 bits 
respectivamente. El limite establecido para los falsos 
positivos es el 2 % por lo tanto, los valores en que el TIP sea 
inferior del 98% no se han considerado como válidos. Por 
otro lado, se ha diferenciado el caso en los que se consideraba 
un canal sin ruido y el caso con un canal con ruido AWGN. 


1,00 
TIP 
0,99 
0,98 1 
2 4 6 8 10 12 14 16 
H of attackers 
(a) M = 128 bits sin AWGN 
1,00 
——ERA - Hard 
——ERA - Soft 
TIP ——MAJ - Hard 
——MAJ - Soft 
—— AVE - Hard 
0,99 —— AVE - Soft 
——COl - Hard 
——COI- Soft 
0,98 T 7 1 1 
2 4 6 8 10 12 14 16 
Hof attackers 


(b) M = 128 bits con AWGN 


Figura 1. Resultados para M=128 bits 


Los valores del TIP en función de MM, el método de 
confabulación, la presencia O ausencia de ruido en el canal 
y el tipo de decodificación (hard o soft) se muestran en 
las figuras 1 y 2. Como podemos observar, los métodos de 
ataque por mayoría y media son los que ofrecen un mejor 
rendimiento des del punto de vista de la decodificación. Este 
resultado es mejorado cuando el descodificador utiliza la 


1,00 


TIP 


——ERA - Hard 
——ERA - Soft 
——MAJ - Hard 
——MAJ - Soft 
—— AVE - Hard 
——AVE - Soft 
——CO! - Hard 
——-CO! - Soft 
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(a) M = 256 bits sin AWGN 
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(b) M = 256 bits con AWGN 


Figura 2. Resultados para M=256 bits 


salida soft en lugar de la hard. 


Podemos observar que cuando el número de traidores 
aumenta, el rendimiento empeora hasta el punto en el que 
el TIP disminuye por debajo del 98 %, momento en el que 
se considera que el sistema no es viable. Por otro lado, 
observamos que la presencia de ruido no afecta todos los 
sistemas de confabulación del mismo modo. Mientras que 
cuando la confabulación escogida por los atacantes es la 
media, el ruido provoca una caída de rendimiento, en cambio, 
la presencia de ruido apenas afecta cuando la confabulación 
se realiza mediante el método de mayoría. 


En cuanto a la capacidad del sistema, teniendo en cuenta 
que nuestro sistema esta dimensionado para 1024 usuarios, 
podemos comprobar que, si des de la capa de watermarking 
se puede forzar que los únicos ataques de confabulación 
posibles sean el de media o el de mayoría, y el sistema de 
decodificación es soft, podemos llegar a identificar, aún con 
la presencia de ruido AWGN, un traidor de un grupo de 28 
con una probabilidad de éxito del 98 % con tan solo 512 bits 
de marca (M = 256). Cabe destacar que esto significa que 
más del 2,7% de los usuarios del sistema participan en la 
confabulación, lo cual es un valor extremadamente grande. 
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VI. CONCLUSIONES 


El presente artículo discute los resultados obtenidos 
con la utilización de los códigos de LDPC como códigos 
fingerprinting para combatir ataques de confabulación. Se 
ha mostrado mediante simulaciones que la probabilidad de 
identificación de traidores (TIP) decrece cuando el número 
de usuarios que participan en la confabulación aumenta. Aún 
así, el algoritmo SPA presenta un rendimiento excelente con 
unas longitudes de código relativamente pequeñas aunque el 
número de atacantes sea sustancial. 


En este sentido se han conseguido probabilidades de 
éxito superiores al 98% con 28 confabuladores de entre 
1024 usuarios. En cualquier caso, cabe destacar que el 
rendimiento crece de forma sustancial cuando la longitud de 
la marca aumenta. Por otro lado, aunque los resultados se han 
condicionado a distintos tipos de ataques de confabulación, 
estos ataques se pueden forzar en función del tipo de 
watermarking con el que se integre este esquema de 
fingerprinting. 


Finalmente, aún teniendo en cuenta el estado embrionario 
de esta aplicación de los LDPC, los resultados preliminares 
aquí expuestos animan a seguir investigando en este camino. 
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